On Tuesday, October 9, 2012 11:14:48 AM UTC+2, Carsten wrote:
> Hi Thomas, 
> Am 09.10.2012 09:35, schrieb Thomas Ferris Nicolaisen: 
> > So, if you want to make an upgrade of for example lua, you first 
> download and unzip it into 
> > /vendor/ExtLibs/lua/, make some adaptions, and then merge it into trunk 
> and any other branch 
> > where you want to perform the upgrade. Is this correct? 
> Yes, this is correct: 
> In /vendor/ExtLibs/lua/ (or currently in fact in vendor/lua/) the newer 
> version "overwrites" the 
> old one (no custom adaptions here!, all code in vendor is "pristine", 1:1, 
> as it was obtained 
> from the vendor). 
> The subsequent merge to trunk/ExtLibs/lua/ makes sure that the old version 
> that is there is 
> updated to the new version while "trunk-local" customizations/adaptions 
> are preserved. 
> > As a thought-experiment: Set aside the git-svn conversion issues for a 
> moment, and imagine, how 
> > would this event (a lua upgrade) be done in the optimal Git repository 
> structure? 
> Exactly analogous to 
> http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/ 
> In the words of my example: 
> Have a branch named "vendor" that contains only the ExtLibs/ directory (so 
> that its structure 
> matches that of branch "master"). (In opposite words, other project 
> directories that are in 
> "master" as siblings of ExtLibs/, are not in branch "vendor"). 
> A lua upgrade would checkout branch "vendor", update lua as before 
> ("overwrite" fashion, 
> pristine), and commit. 
> Check out "trunk", then merge in "vendor". 
> As you see it's very straightforward and simple. :-) 
> I'm honestly a bit surprised that this kind of question doesn't occur more 
> often, considering 
> (or assuming) that many other projects that convert from SVN to Git have 
> "vendor branches", too. 

A branch in Git is uusally a branch of *what is the main contents of the 
repository*, not some arbitrary content. As I said above, submodules were 
invented for this purpose, to avoid filling up your own repositories with 
things that don't really belong there. 

That said, I imagine that your model should work. It's like having 
permanent feature-branches, which are never updated with the development in 

So, I imagine the following.

You first clone  the *cafu* repository. Inside *cafu* you get 
subdirectories like ExtLibs/lua, ExtLibs/zlib and so on. 

You then clone each of the vendor repositories, and transform them into 
having the structure you want. See the man page for filter-branch, there's 
an example for "*To move the whole tree into a subdirectory*".

Now you have an adjacent repository *lua*, which contains 

So, now you want to first fetch the contents of *lua* into your 

cd cafu
git remote add lua ../lua
git fetch lua

So, they're both in there now, but there's nothing to connect commits in 
lua/trunk to the commits under cafu/ExtLibs/lua. These links you have to 
create manually using grafts.

Now, you can start creating these links using grafts. For each commit 
inside cafu/ExtLibs/lua that was a merge from vendor (you need to find 
these manually), look up its parent in the remotes/lua/master branch, and 
graft them together.

Is this a line of thought you have tried out in practice? I know it will be 
a lot of work depending on how many commits there have been in vendor, but 
it's the only way you can get there, I think.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to