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

[Junio C Hamano <gitster@pobox.com>]

Bill Priest <priestwilliaml@yahoo.com> writes:

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

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.