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 
master.

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 
/vendor/ExtLibs/lua/[content]. 

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

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 
https://groups.google.com/d/msg/git-users/-/fTTBy6gkNFQJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to