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 approach. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html