Re: How to selectively recreate merge state?

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 11, 2009, 23:46 UTC
Message-ID: <7vk4wtysyu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <76718490912111418i6b59056eq69671979613749f7@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

> Also, I think we could improve the output of "git status" during merge
> resolution, both before and after conflicts have been resolved in a
> file.

I think you are talking about something that is largely unrelated, even though they would be a pair of good issues to discuss. The solution to them does not have much to do with what we have been discussing so far in this thread, and actually should be much simpler, which is a good news ;-).

Show 13 quoted lines

> $ git status
> foo: needs merge
> # On branch master
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #	unmerged:   foo
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> "unmerged" is good. But the instruction to use "git checkout --
> <file>" to discard changes is wrong in this context:

You should be able to change this without any "unresolve" index extension added to the index. Just notice an unmerged entry in the index and reword the message accordingly.

More importantly, note that "git status" lists "unmerged" entries in a separate section in its output in 1.6.6 (and has been so on 'master' for some time) and your problem report needs to be adjusted for a more recent reality. Here is what you would get:

        $ git status
        # On branch pu
        # Changes to be committed:
        #   (use "git reset HEAD <file>..." to unstage)
        #
        #       modified:   builtin-send-pack.c
        #       modified:   remote.c
        #       modified:   remote.h
        #       modified:   transport.c
        #
        # Unmerged paths:
        #   (use "git reset HEAD <file>..." to unstage)
        #   (use "git add <file>..." to mark resolution)
        #
        #       both modified:      transport-helper.c
        #

One problem we can see is that 'use "git reset HEAD <file>..." to unstage' is an invalid advice if we are in the middle of a merge, but is perfectly valid if this were during "rebase", "am -3", "cherry-pick" and "revert".

The solution to this issue is exactly the same as the next one.

Show 9 quoted lines

> $ git status
> # On branch master
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #	modified:   foo
> #
>
> Well, yes, I can use git reset, but that just keeps my side of the merge.

If the conflict was coming from "rebase", "cherry-pick", etc., there is nothing but one side, as there is no merge going on, and what "git reset" does is exactly what the message tells you---to unstage.

I think "git status" should notice that the next commit you would make from this state will be a merge commit, and remove these "reset HEAD" lines. Once you "git add" to resolve, it makes _no_ sense to reset to HEAD, if you are concluding a merge. Until "update-index --unresolve" is revived as a modern version (and I suspect that a more logical Porcelain interface would be a new option "reset --unmerge <paths>..."), we should simply drop "reset HEAD" advice when we are in a merge.

Note that the "unresolve" index extension will not help you at all in order for you to decide if you are going to make a merge commit. You should instead ask "does .git/MERGE_HEAD exist?", and it is something you should be able to implement directly on top of upcoming 1.6.6 release.