Re: Migrating SVN to Git, and preserve merge information

From: Santi Béjar <santi@agolina.net>
Date: Apr 11, 2012, 11:13 UTC
Message-ID: <CA+gHt1DPSkbwyXzt4SHL=1btLJW8mVYrWORU8Wk2riW4v+SCvA@mail.gmail.com>
In-Reply-To: <4F8531B3.9030501@nekoconeko.nl>

On Wed, Apr 11, 2012 at 9:24 AM, Nick Douma <n.douma@nekoconeko.nl> wrote:

Show 9 quoted lines

> Hi Andrew,
>
> On 11-04-12 00:57, Andrew Sayers wrote:
>> Would I be right in thinking that a commit like "Merged r100,r101,r102
>> from trunk" will create three grafts?  If so, that might be the problem.
>
> One SVN 'merge' commit will generate one graft. The graft itself will
> contain all revisions mentioned in the merge commit, and whatever the
> original git parent was before the graft.

This graft does not represent the SVN ´merge´. There are two types of SVN ´merges´, and you are describing the cherry-pick one. So you have to represent them as such, as cherry-pick. And a cherry-pick in git is just a normal commit, it just happens to apply to a different branch (commit), it normally has the same commit message (except some people prefer to add "(cherry pick from commit ...)". And I think this is just what you are looking for.

So, I would recommend you to just rewrite the SVN commit id with git commit sha1. Only in the case where you have a real merge (rev XXX: Merge all history up to rXXX-1 from trunk), you use the graft approach.

Show 13 quoted lines

>
>> Git differentiates between "merges" (which include every commit up to
>> and including the specified one) and "cherry-picks" (which just include
>> the specified commit), whereas SVN calls both of these "merges".  Grafts
>> are a way of creating "merges" rather than "cherry-picks" (which git
>> doesn't have any metadata for), and it's not at all easy to get "merge"
>> data out of SVN in the general case.  Having said that, it's often a
>> good enough heuristic to pick the highest revision number mentioned in
>> the commit message and pretend it's a merge.
>
> The way we 'merged' in SVN was indeed more like cherry-picking, but I'm
> looking to display this information as a merge in Git. I also would like
> to include all revisions if possible.

But git needs a meaningful history!! If you use merges to represent cherry-picks it will confuse some of the git tools.

If the question is to "display this information" in a meaningful way just use the approach outlined above.

>
> The real problem I seem to be having is not completely understanding how
> Git grafts work, because I think I'm hitting some kind of limitation or
> bug, or just not using it right.

If gitk --all freeze theres is definitly a bug somewhere. I don´t really know, but maybe the problem is that some parents in your grafts are descendent of the others.

Anyway, we need a minimal method to reproduce it.

HTH, Santi