Re: How to selectively recreate merge state?

From: Jay Soffian <jaysoffian@gmail.com>
Date: Dec 11, 2009, 22:18 UTC
Message-ID: <76718490912111418i6b59056eq69671979613749f7@mail.gmail.com>
In-Reply-To: <7v3a3h48lz.fsf@alter.siamese.dyndns.org>

On Fri, Dec 11, 2009 at 2:24 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

>  - This was done about only one year after git was born.  You should not
>   take it granted that the workflow it wanted to support makes sense.
>
>   Considering that using "git add" to mark the resolution is to declare
>   that you are _finished_ with that path, using it for other purposes
>   (e.g. leaving a note that says "I've looked at and have one possible
>   resolution in the file in the work tree, but I haven't verified the
>   result yet", which is what the commit talks about) is simply an
>   (ab|mis)use of the index.  Lossage of higher stage information by this
>   misuse is user's problem, and there is this thing called pen & pencil
>   the user can use for taking notes if s/he does not want to lose the
>   original conflict information from the index.

Just a little more data. What happened in my case was that I was using a visual merge tool and accidentally saved instead of canceled, so git mergetool automagically added my results. I had resolved about 15 files, and made a mistake with only one, so I was sad when I couldn't determine how to unresolve that one file (at which point I saved off the other 14 resolutions, reset, re-did the merge).

My intuition led me to try "git reset <path>" since that's how one normally unstages additions to the index. But of course that didn't work, where "of course" only makes sense if you know how the index is used during a merge.

Show 6 quoted lines

> In fact, considering that there are many ways conflicts can be left in the
> index and there are only two ways that they are resolved in the index by
> the user (and both eventually uses a single function to do so), it would
> make perfect sense to do the following:
>
> [...excellent list of suggestions elided...]

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. Immediately after a conflict, the conflicted files are shown as "unmerged":

$ 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:

$ git checkout -- foo error: path 'foo' is unmerged

Then, after resolving foo and adding it:

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

So I think with your suggested changes to the index, we can do better with the status output during a merge.

j.