Johan Herland wrote: > --- a/Documentation/git-merge.txt > +++ b/Documentation/git-merge.txt > @@ -13,6 +13,7 @@ SYNOPSIS > 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? References: http://thread.gmane.org/gmane.comp.version-control.git/136356/focus=136773 http://thread.gmane.org/gmane.comp.version-control.git/151799/focus=151812 > +--abort:: > + Abort the current conflict resolution process, and > + reconstruct the pre-merge state. > ++ > +Any uncommitted worktree changes present when the merge started, > +will only be preserved if they have not been further modified > +since the merge started. Ah, maybe I see: is the problem this procedure? 1. Make changes to file foo.c (without staging them). 2. Try a merge (which cannot touch foo.c, or the merge would have been aborted automatically) which fails with conflicts. 3. As a result of semantic conflicts, make some changes to foo.c. 4. Wish to return to the state from the end of step 1. But I find the following more likely: 1. Make changes to file foo.c (without staging them). 2. Try a merge (which cannot touch foo.c, or the merge would have been aborted automatically) which fails with conflicts. 3. Walk away in disgust. 4. Return, make some more changes to foo.c. 5. Notice the merge in progress --- oh! --- and abort it. > --- a/t/t7609-merge-abort.sh > +++ b/t/t7609-merge-abort.sh > @@ -3,95 +3,271 @@ > test_description='test aborting in-progress merges' > . ./test-lib.sh > > +# Set up repo with conflicting and non-conflicting branches: > +# > +# master1---master2---foo_foo <-- master > +# \ > +# --clean1 <-- clean_branch > +# \ > +# --foo_bar <-- conflict_branch [It might be nice to include this in test_description for use by "./t7609-merge-abort.sh --help".] > +# - 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. In other words, if the change is also on a remote branch that you want not to merge with anyway, it is not likely to be terribly important to preserve it in the local tree. (This is a trade-off between convenience in two different scenarios.) Hope that helps (sorry for the ramble). -- 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