Jay Soffian <jaysoffian@xxxxxxxxx> 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
;-).
> $ 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.
> $ 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.
--
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