Re: Untracked working tree files

On Wed, 15 Oct 2008, Linus Torvalds wrote:

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

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