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
> Exactly analogous to
> 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
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 email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at