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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
