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

[Bryan Jacobs <bjacobs@woti.com>]

On Fri, 02 Sep 2011 12:01:09 -0700
Sam Vilain <sam@vilain.net> wrote:

> That's one way to do it; in fact, if the trees match you don't need
> to do anything complicated like cherry-pick.
> 
> ie, say you're committing
> 
>     r1---A---B---C---D
> 
> and it blows up at
> 
>     r1--r2--r3--C---D
> 
> So long as the tree from the fetched r3 == the tree from B, then you
> can just go ahead and write out new commits for C and D without doing
> any merging (ie cherry-pick or rebase).  You could also put merge
> commits back the way they were, too.

When you say "write out new commits" you mean create a commit object
with the same contents, but a different parent? Does git-svn do this
somewhere already?

> If they don't match, then something went wrong with the push really,
> or there is something weird going on.  I'd try to avoid using cherry
> pick automatically in situations like this.  There are too many error
> modes, and if it only happens when you don't know what's going on,
> it's not a good idea to try to fix that.  If it /is/ a sufficiently
> unlikely error (ie, the trees not matching as above), then it would
> be better to simply bomb out and provide two commands:
> 
> * a 'git reset' command to restore to previous state (ie, before the 
> dcommit)
> * a 'git rebase' command to attempt to put the new history on top of
> the new upstream.  Rebase doesn't work with merges of course but it
> still should help the user figure out what to do.
> 
> Another benefit of this approach is that you don't need to muck with
> the WC + index at all, no matter what happens.

All of the above sounds good to me. I haven't taken the time to
understand how git-svn sends changesets upstream (I only know it mucks
with the WC from empirical experience) so I don't know how easy it would
be to change the methodology, though.

Would this also mean we could dcommit from a dirty checkout? Having to
stash/unstash is a nuisance.

> Sam
>