4

I want all project files like source code to be part of the repository. For simplicity reasons all work is done on the development branch. Furthermore, I want to include additional project material like pdf files. I do not want to add them to the development branch. Until now I came up with the following strategies.

  • Strategy 1 is to create a separate branch material and add the pdfs. The branch shares some history with its parent branch.
  • Strategy 2 adapts the first strategy but also merges the commits of the material branch into the development branch from time to time. (I do not want this, and it is a pita.)
  • Strategy 3 is to create an orphan branch that does not share the history of the source code, for example.
  • Strategy 4 is to follow strategy 1 or 3 and additionally create a submodule that represents only the material branch of the "main" repository. If this is possible the working directory would show the development branch and the material branch at the same time.

The disadvantage to all strategies is that I can not access the files in the working directory when I checked out another branch.
How can I work on the development branch and at the same time have the material available in the working directory? If it is easier to you to imagine, the material could also be the documentation.

Edit: I added strategy 4. after reading Seth Robertson's answer.

Community
  • 1
  • 1
JJD
  • 50,076
  • 60
  • 203
  • 339
  • Why don't you want to include additional project material on the development branch? – wnoise Jun 08 '11 at 23:08
  • Imagine the "additional material" is a sequence of test exploring a new library. They are not unit tests for the framework you are working on. But still you do not want to through them away. – JJD Jun 08 '11 at 23:17

1 Answers1

2

Well, you could split the pdfs into a separate repository and use something like gitslave or git-submodules to link the two projects together.

One extension of this idea is, when using git-submodules (not gitslave), is that you might be able to actually make the "other repository" your local repository on a different branch (I don't see how git could tell this apart from some other case—with the possible exception of locking if you actually use the same repo instead of cloning from the master upstream).

Of course, with git-submodules you might (or might not) have problems with merging the SHA of the pdf repo. gitslave would not have that problem.

Seth Robertson
  • 30,608
  • 7
  • 64
  • 57
  • I added the 4. strategy after reading your answer. Maybe you ment the same but I am not sure if I understand right. Regarding `gitslave`: I did not know it and will read through. – JJD Jun 08 '11 at 23:22
  • @JJD: Strategy 4 is one of the options I mentioned. Before you finalize your choice with git-submodules play with it, specifically with the pain of having to update the "material" branch and what you need to do to get the "development" and "main" branches to see the updates you made. – Seth Robertson Jun 08 '11 at 23:28
  • Why not bake in gitslave into git? Everyone would have it – Adam Dymitruk Jun 09 '11 at 03:35
  • @adymitruk: I think we digress, but since gitslave is a meta-script which calls git and does nasty things to the output, I don't see it ever being in core-git. It might be in contrib, perhaps – Seth Robertson Jun 09 '11 at 04:45
  • I'd love for it to be a contrib project – Adam Dymitruk Jun 09 '11 at 05:19
  • Actually, I also would prefer a solution that works with git-core tools. Otherwise it is not practicable using it on various computers running various operating systems. – JJD Jun 09 '11 at 16:00