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

[Jonathan Nieder <jrnieder@gmail.com>]

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