Re: Migrating SVN to Git, and preserve merge information

On Wed, Apr 11, 2012 at 9:24 AM, Nick Douma [off-list ref] wrote:

Hi Andrew,

On 11-04-12 00:57, Andrew Sayers wrote:

quoted

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.

quoted

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