Subject: Re: [PATCHv5 23/23] Provide 'git merge --abort' as a synonym to 'git reset --merge'

From: Johan Herland <[email-masked]>
Date: Tue, 26 Oct 2010 03:26:32 +0200

On Monday 25 October 2010, Johan Herland wrote:
> On Monday 25 October 2010, Jonathan Nieder wrote:
> > Johan Herland wrote:
> > >                                                  However, if there
> > > +were uncommitted changes when the merge started (and these changes
> > > +did not interfere with the merge itself, otherwise the merge would
> > > +have refused to start), and then additional modifications were made
> > > +to these uncommitted changes, 'git merge --abort' will not be able
> > 
> > > +reconstruct the original (pre-merge) uncommitted changes. Therefore:
> > I do not find this clear.  Could you give an example?

[...]

> > > +# - dirty worktree before merge matches contents on remote branch
> > 
> > Or maybe this was the example.  Here was Junio's explanation of it:
> > | It will discard the change, the one you independently picked up, but
> > | the change agreed with what was done by the the trash history that
> > | you are cancelling merge with.  You wouldn't miss losing the same
> > | change as in that trash history.
> 
> Yeah, but I've now found that I failed to test that case. Will be fixed
> in the next iteration.

Instead of sending an entire new patch series when I've only changed the 
last two patches, I'm gonna send only those two patches, marked "PATCHv5.1", 
as a reply to this email.

Hope this is ok,

...Johan

-- 
Johan Herland, <[email-masked]>
www.herland.net