can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"

All,
  I merged from one branch to another and had lots of
conflicts.  I've resolved a set of files from the
conflicts (in a directory) and did a git-add on this
set of files.  I wasn't able to commit these files. 
On IRC I was told that all files must be resolved
before I can commit any of them.  This seems pretty
limiting.  Why is a commit after a merge all or
nothing; I thought that git  figured out merges and
such by the differences between files??

Bill

      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

Bill Priest wrote:

You have to resolve _conflicts_ only. The rest is added automatically. See git-status, git diff --merge, git ls-files -u.

Bill Priest <priestwilliaml@yahoo.com> writes:

You have two parallel development lines that lead to A and B and trying to come up with a "merge" M:

         o---o---A
        /         \
    ---o---o---B---M

What property should the merge commit "M" have? It must keep the changes made on the upper line to make it better than B, and it must keep the changes made on the lower line to make it better than A.

Let's say both upper and lower lines of development touched files frotz and xyzzy in overlapping, different ways. You try to merge A while you are at B and see conflicts in these two files.

Let's say you resolved frotz; the contents in frotz is in a desired shape, i.e you have the changes you want from the line led to A and the other line led to B. But you haven't resolved xyzzy yet.

You seem to want to make this half-resolved state as a commit. First question: what contents would you want to commit for xyzzy?

If you commit the contents from B (because you started from it), then it should not be recorded as a proper merge. If you did so, merging that back to A would obliterate all the work done up to A to file xyzzy:

         o---o---A...X
        /         \ .
    ---o---o---B---*
 
because merge base of A and * (I am marking it differently because such
an incomplete merge should not be made) is A, so the result (X) will be
the half-merge * itself (fast forward).  That's not a merge as it is not
better than A -- you discarded improvements made to xyzzy by people who
built up to A.

This is inherent to what a merge is. With proper understanding of what a merge is, you would not feel this limiting at all.

Having said that, I think something like the following _could_ be done, although I do not know if it makes much sense.

(1) Try merge, see it conflict, resolve only a part of it, and record
    the result as "WIP to merge in A".  Do not record it as a merge, as
    it is not.  diff between B and M will contain a squash merge of A on
    top of B minus the changes to the path xyzzy.

         o---o---A
        /         
    ---o---o---B---M

(2) Fix up the conflicts in xyzzy to resolve the conflicts fully, and
    record the result as "Final merge of A into B".  This should be
    recorded as a merge, as the result is "keeping changes done on both
    branches to come up with something better than either of them."

         o---o---A---,
        /             \
    ---o---o---B---M---N

If you look at the topology a bit differently, the above actually makes some sense:

         .---o---o---A
        /             \
    ---o---o---B---M---N

That is, instead of merging A into B, you made "preparatory changes" to branch B in order to make it easier to merge A. That's what the commit M is about.

Then you merge A on top of M. In reality, because the difference between B to M contains most of the squash merge of A into B, such a merge N will contain many accidental clean merges. But in git, accidental clean merges are not a problem (people can apply the same patch to their trees and later their branches can be merged).

But "git commit" after a conflicted merge will always create a merge, and there is no canned option to do multi-step merge like the above.

You can still do that by hand, by doing something like:

	$ git merge --squash A
        $ resolve only partly
        $ git commit -m 'Prepare to merge A'
        $ git reset --hard
        $ git merge A
	$ resolve the rest
        $ git commit -m 'Fully merged A'

For such a multi-step merge to make sense, the change between B---M should make sense by itself for people who have to read such a history later. Such a half-a-squash-merge may probably not make sense by itself in most cases, so I suspect the above workflow would not be useful in general.