On Fri, 02 Sep 2011 11:40:25 -0700 Sam Vilain <sam@xxxxxxxxxx> wrote: > On 9/2/11 11:07 AM, Bryan Jacobs wrote: > > For this particular case, it works well: svn:mergeinfo is populated > > in such a way that the local merge history is recreated when > > another git-svn user pulls down the repository. This patch thus > > allows to git users to exchange branching and merging development > > through a central SVN server without loss of fidelity and without > > explicitly manipulating the mergeinfo property by hand. > > Whee! That's what I was intending when I wrote the original change. > I might have written it myself back in 2008 or whenever it was, but I > found I didn't actually have any SVN projects I was sending commits > to, let alone merges. git-svn is a project with a continually > atrophying userbase :-). Thanks for picking it up. > Glad to hear it. I think there's still work to be done, mostly because I'm not very familiar with the git codebase and the "right" way to do things, but I want this to work. > > r1 --- r3 -- r4 > > \ > > r2 --- E > > > > F is lost and cannot be cherry-picked back onto the WC, as any > > files created in E are already present but untracked locally. > > Are r1 and r2 supposed to be on the same SVN branch? No, different SVN branches. > > Overall, I could believe that. Perhaps it is simpler to detect those > situations in advance and insist the user dcommits them > independently, although it appears to me that it would apply to any > dcommit which failed for any reason part way through. So perhaps > there is a wider justification for fixing that. I could do a pass through all the commits which are about to be sent out to SVN to check if this is going to happen, yes. But I think a better solution would be to change how the changes are replayed by git-svn dcommit: right now, all changes are applied to the WC, then it sequentially does an add+dcommit for each patch? Right? I think it might be better to reset --hard to the parent, then pick each change into the WC+index before committing. That way if you abort early, cleaning up just consists of rebasing the stack onto the last change you sent upstream. If I get around to making git-svn put its stuff into notes, this would be a lot easier since you could just reset --hard back to the original HEAD, since none of the earlier commits would have been mangled. But of course everyone who already imported a repo would be SOL if the new version relied on that Hippocratic behavior... > Sam -- 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