Re: Untracked working tree files

On Wed, 15 Oct 2008, Linus Torvalds wrote:

 - a merge goes south with a data conflict, and since it's all automated, 
   you just want to throw it away.

Actually, with your filename, I suspect the conflict would be not a real 
file content, but more of a "delete" conflicting with a modification to 
that file. IOW, I'm guessing that the thing you hit with 
arch/x86/kernel/apic.c was that some branch you pulled:

 - created that file

 - deleted arch/x86/kernel/apic_[32|64].c

 - the old file got marked as a rename source for the new apic.c and 
   there was a data conflict when trying to apply the changes.

as a result, your working tree would have that "apic.c" file in it, but 
with conflict markers, and marked as unmerged.

When you then do "git reset --hard", it will just ignore unmerged entries, 
and since the original tree (and the destination tree) match, and neither 
of them contain apic.c either, git will totally ignore that file and not 
even try to remove it (since it wasn't there originally).

So you do "git reset --force" to do that.

It's "--hard", not "--force". Yeah, the git reset flags are insane. As is 
the default action, for that matter. It's one of the earliest interfaces, 
and it's stupid and reflects git internal implementations rather than what 
we ended up learning about using git later. Oh, well.

But 'git checkout -f' (which is nicer from a user interface standpoint) 
has the exact same logic and I think shares all the implementation. I 
think they both end up just calling "git read-tree --reset -u".

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?

			Linus