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

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