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

On Monday 25 October 2010, Johan Herland wrote:

On Monday 25 October 2010, Jonathan Nieder wrote:

quoted

Johan Herland wrote:

quoted

                                                 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

quoted

+reconstruct the original (pre-merge) uncommitted changes. Therefore:

I do not find this clear.  Could you give an example?

[...]

quoted

quoted

+# - 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, [off-list ref]
www.herland.net