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

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

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