Re: [spf:guess,iffy] [PATCH] git-svn: teach git-svn to populate svn:mergeinfo

From: Bryan Jacobs <bjacobs@woti.com>
Date: Sep 2, 2011, 18:49 UTC
Message-ID: <20110902144922.383ed0f1@robyn.woti.com>
In-Reply-To: <4E612319.7030006@vilain.net>

On Fri, 02 Sep 2011 11:40:25 -0700 Sam Vilain <sam@vilain.net> wrote:

Show 14 quoted lines

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

Show 8 quoted lines

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

Show 6 quoted lines

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