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