Sam Vilain <sam@xxxxxxxxxx> wrote: > On 9/2/11 12:42 PM, Bryan Jacobs wrote: > >On Fri, 02 Sep 2011 12:01:09 -0700 > >Sam Vilain<sam@xxxxxxxxxx> wrote: > > > >>That's one way to do it; in fact, if the trees match you don't need > >>to do anything complicated like cherry-pick. > >> > >>ie, say you're committing > >> > >> r1---A---B---C---D > >> > >>and it blows up at > >> > >> r1--r2--r3--C---D > >> > >>So long as the tree from the fetched r3 == the tree from B, then you > >>can just go ahead and write out new commits for C and D without doing > >>any merging (ie cherry-pick or rebase). You could also put merge > >>commits back the way they were, too. > >When you say "write out new commits" you mean create a commit object > >with the same contents, but a different parent? Does git-svn do this > >somewhere already? > > I guess it doesn't, but if it did it would certainly make this > easier. I'm not sure why it would need to modify the WC at all. > Eric, is this just historical or is there a better reason for that? dcommit needs to continually rebase because it's possible somebody else may make a commit to the SVN repo while a git-svn user is dcommiting and cause a conflict the user would need to resolve in the working tree. At least I think that was the reason... There is also the "commit-diff" command in git-svn. It was the precursor to dcommit which requires no changes to the working tree. -- Eric Wong -- 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