Re: Untracked working tree files

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 15, 2008, 22:06 UTC
Message-ID: <7v3aixqzrn.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org>

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

Show 8 quoted lines

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