thank you very much for your reply!
I know it was a long post, and I very much appreciate your having worked
Am 2012-10-07 23:42, schrieb Thomas Ferris Nicolaisen:
It is indeed a large post and hard to read out the question(s) in there. In the
part, you describe some complications with the live/pristine branches, but you
write that you have already solved this problem? I find the connection with the
and the last part a bit unclear.
You're right, I'm very sorry about it.
I guess it's the result of me being still in the learning process... there are things
that I felt that I had to circumscribe, in lack of knowing the proper, short,
I tried to outline what I did and what want well so far:
a) For the "vendor branches" I found the special-case solution described at
b) Using that, all conversions of my websites worked well, requiring grafting in one
case. Practical use of these conversions works perfectly as well.
So the "websites" stuff is completely done and out of the picture.
You might get more replies if you try to isolate a smaller example, and ask
questions one at a time.
Yes, I'll complete this answer to you first, and then in a new, separate post will
re-phrase my question in a smaller example, later today.
I'm not quite sure how the external libraries are versioned in relation to your
project (with the trunk/branches/tag structure). Before I go on to think about
could do lots of sub-tree merging and filter-branching to get these external
into your repository, I want to ask if you really want to do this.
Including the sources of 3rd party libraries is exactly what git-submodules are
for, and even before I do this I would consider if it is possible to get away
rather some binary dependency declaration in the build-tool instead (this might
fitting for your project, but it's worth considering).
Even if you do your own modifications of lua or the other libraries, it is
tracking them in their own repositories, and then load them in using submodules.
Some aspects about our external libraries in ExtLibs:
Binary dependencies would only work in a subset of our use cases: Obviously, we don't
need our own copy of zlib under Linux, but we do under Windows.
With some of the libraries (e.g. wxWidgets) we sometimes have specific needs to the
exact version that is used, and occasionally make small changes in the libraries
themselves. It's rare, but when done it's also crucial, such as bug-fixes, feature
patches, customizations, etc.
For our repository users, all this should be as carefree as possible, if possible we'd
like to continue to provide them with everything that they need with a single "git clone
All the libraries in ExtLibs are lightweight and small in size, so performance or
bandwidth is not an issue.
Our use of vendor branches was of course born long years ago, in the Subversion days
when most libraries where not available as Git repositories: "Occasionally drop .tar.gz
archives of their latest public release into our vendor branches, then merge them to
master in order to not overwrite our customizations."
Using submodules, we would not want to depend on the Git repositories of the library
vendors, so we had to create our own "ExtLibs" Git repository. That, in turn, would be
managed via .tar.gz drop-ins as before.
From what I've read about submodules, they seem to come with inherent problems that I'd
rather try to avoid, e.g. as described at
http://git-scm.com/book/en/Git-Tools-Submodules (the book by Loeliger and that by Haenel
express similar concerns).
A case where I can see how submodules would be useful is for example if Autodesk made
their "Autodesk FBX SDK" available as a Git repository. This library is so huge that
we'd not want to have it in our main repository, plus there are legal restrictions that
don't allow us to do so. Also, we'd never like to modify anything in there.
To my understanding, this would be a perfect case for submodules.
In summary, even though I fear that my understanding of submodules is incomplete,
*subtrees* seem to be a better solution to the problem.
(And I had hoped to avoid even those, in the spirit of the happygiraffe.net blog post,
i.e. having a branch named "vendor" that has nothing but the ExtLibs directory with the
.tar.gz drops of the libraries.)
With this in consideration, what is the first thing you need to solve? You
you haven't been able to convert with all the merges intact. Is this point
complete the conversion?
To my understanding, yes:
Merging later (using grafts and filter-branch) would change the SHA-1 sums of all child
commits, essentially making any public clone of the repository incompatible (or at least
require everyone to rebase), would it?
Also, one of our important points in switching to Git is the better merging, i.e. when a
new version of one of the libraries in ExtLibs is released, we would like to make
Ok, as said above, I'll come up with a shorter, stand-along description of my problem
and question in a separate post.
Many thanks for your help so far, and best regards,
Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
Learn more at http://www.cafu.de
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at