From: Johan Herland Date: Tue, 26 Oct 2010 01:26:32 GMT Subject: Re: [PATCHv5 23/23] Provide 'git merge --abort' as a synonym to 'git reset --merge' Message-ID: <201010260326.33200.johan@herland.net> In-Reply-To: <201010251203.00389.johan@herland.net> 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, www.herland.net