Linus Torvalds <torvalds@linux-foundation.org> writes:

quoted text
> On Wed, 15 Oct 2008, Linus Torvalds wrote:
>> 
> It's quite possible that we should remove unmerged entries. Except that's 
> not how our internal 'read_cache_unmerged()' function works. It really 
> just ignores them, and throws them on the floor. We _could_ try to just 
> turn them into a (since) stage-0 entry.
>
> Junio?

I'd agree that dropping unmerged entries to stage-0 when we can would make
sense.  An conflicted existing path would get an stage-0 entry in the
index, which is compared with the switched-to HEAD (which could be the
same as the current one when "git reset --hard" is run without a rev), we
notice that they are different and the index entry and the work tree path
is overwritten by the version from the switched-to HEAD.  For a new path
that a failed merge tried to bring in, we notice that the switched-to HEAD
does not have that path and happily remove it from the index and from the
work tree.  All will go a lot smoother than the current code.

I am not sure what should happen when we can't drop the unmerged entry
down to stage-0 due to D/F conflicts, though.  IIRC, read-tree proper
would not touch the work tree in such a case, but merge-recursive creates
our and their versions with funny suffixes, which will not be known to the
index and will be left in the working tree.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html