4

I have a repository that contains the software in branch master and its homepage in branch gh-pages. The project contains an examples directory with source files that should be contained in the master branch. The homepage should contain the compiled examples and possibly also the source files. How can I share the examples (that depend on the master branch to get compiled) between both branches? The desired workflow is:

$ git checkout gh-pages; ls examples/  # directory is empty
$ git checkout master;   ls examples/  # directory contains .tex source files
author.tex
$ make examples && ls examples/        # compiles .tex files to .png files 
author.tex author.png
$ $MAGIC_COMMIT_TO_BRANCH_SELECTED_FILES gh-pages author.png author.tex
$ git checkout gh-pages; ls examples/
author.tex author.png

Branch gh-pages may already contain the examples so just switching to this branch will overwrite the newly compiled files. The compiled files should not be committed to the master branch. I thought about creating another branch examples but this does not really make it easier. If git submodule could point to specific branches (can they?) I could create an examples branch that is used in the other branches as submodule. Moving the examples to another repository may work but I'd prefer to keep all in one repository. Maybe there is some merge manager or cherry-picking magic?

Jakob
  • 3,570
  • 3
  • 36
  • 49
  • "switching to this branch will overwrite the newly compiled files": no, git will refuse to switch branches, because doing so would overwrite those files and possibly cause you to lose data. – Cascabel Aug 10 '10 at 20:11
  • Also, you're asking for something very different from just having certain files on two branches (which would be straightforward). You're asking to have one branch contain the compiled versions of the files on another branch. – Cascabel Aug 10 '10 at 20:13
  • You are right - the source files should be on both branches (which could be solved by cherry-picking if I understand it right) but the compiled files should be produced at one branch and committed at another. A chain of make, git-ls-files, copy-to-temp, switch branch, copy-from-temp, commit may solve my problem by an ugly hack. – Jakob Aug 10 '10 at 22:26
  • Jakob: Why don't you want your build files associated with the source code? – Arafangion Dec 16 '10 at 22:27

2 Answers2

1

I dont think you have grasped what version control is all about. At least it seems to me that you are using branches the wrong way. It's the messy repository design that's causing all your problems. It doesn't make any sense to have the source on two branches, while at the same time the compiled files should be produced from one branch and committed on another, then you might as well produce and commit the compiled files on the same branch as the source it's been produced from.

It seems that you are using branches instead of using separate repositories. If you compile code from some source on one branch and commit the files on another branch, how would you know from WHAT version of the source it has been compiled from?

I dont see why you cant just have the source AND the compiled files in one branch, work and compile until you're "done" and then merge the changes into master. Then you have the source and compiled files on two branches, but so what? :) An alternative is to keep the source in one branch, work on the source until you're "done" commit the source and merge the changes into master. Check out the master branch, compile and commit the new compiled files.

rtn
  • 127,556
  • 20
  • 111
  • 121
0

I would create one branch to include all these shared files. Whenever a branch needs a shared file, it can get it using

git checkout workingbranch
git checkout sharedbranch <needed file>

Later you can update simply using the same command

git checkout sharedbranch <needed file>
moibrahim
  • 89
  • 7