Re: Untracked working tree files

Linus Torvalds [off-list ref] writes:

On Wed, 15 Oct 2008, Linus Torvalds wrote:

quoted

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.