Re: Migrating SVN to Git, and preserve merge information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Wed, Apr 11, 2012 at 9:24 AM, Nick Douma <n.douma@xxxxxxxxxxxxx> wrote:
> 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

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google