Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo

From: Eric Wong <normalperson@yhbt.net>
Date: Sep 3, 2011, 08:49 UTC
Message-ID: <20110903084947.GA16711@dcvr.yhbt.net>
In-Reply-To: <4E614AE7.7090706@vilain.net>

Sam Vilain <sam@vilain.net> wrote:

Show 26 quoted lines

> On 9/2/11 12:42 PM, Bryan Jacobs wrote:
> >On Fri, 02 Sep 2011 12:01:09 -0700
> >Sam Vilain<sam@vilain.net>  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