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

[Bryan Jacobs <bjacobs@woti.com>]

On Fri, 02 Sep 2011 11:40:25 -0700
Sam Vilain <sam@vilain.net> 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