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, <johan@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html