From: Bryan Jacobs Date: Tue, 06 Sep 2011 14:00:03 GMT Subject: Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo Message-ID: <20110906100003.4c87daba@robyn.woti.com> In-Reply-To: <20110903084947.GA16711@dcvr.yhbt.net> On Sat, 3 Sep 2011 08:49:47 +0000 Eric Wong 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