Dear Thomas,

thank you very much for your reply!
I know it was a long post, and I very much appreciate your having worked 
through it.

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, unambiguous term.

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 
how one
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 
not be
fitting for your project, but it's worth considering).

Even if you do your own modifications of lua or the other libraries, it is 
still worth
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 (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 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 
write that
you haven't been able to convert with all the merges intact. Is this point 
crucial to
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 upgrading easy.

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

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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to