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

[Bryan Jacobs <bjacobs@woti.com>]

On Sat, 3 Sep 2011 08:49:47 +0000
Eric Wong <normalperson@yhbt.net> wrote:

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

Let me see if I've got this right.

The goal here is to commit each x~..x for each x in A..B, aborting if
the SVN tree is not in state "x~" when the diff arrives.

"commit-diff" appears to be doing exactly what "dcommit" is doing, but
iteratively for each change in linearized A..B, rebasing after each
step. This sounds correct to me, assuming that the "apply_diff" method
will correctly abort if a commit races into the upstream SVN before it
is called. So why am I seeing files added in changes on alternate
branches ending up in the working copy when I abort before apply_diff
is called for the commit which merges them into the present branch?

You can check for this yourself with my patch using the example setup I
gave earlier. You'll see files in the present/untracked state - these
interfere with rebasing the user-created-but-not-SVN-dcommited merge
onto the partially-sent-to-SVN tree.

Bryan Jacobs