On Tue, 21 Feb 2006, Dave Jones wrote: > > For some reason, that shows that file being deleted. > > diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt > deleted file mode 100644 > index e71bc6c..0000000 > --- a/Documentation/cpu-hotplug.txt > +++ /dev/null > @@ -1,373 +0,0 @@ If that file didn't exist in your index, "git diff" wouldn't even show it. So it exists in your index, but not in your working tree. > Hmm, this tree is on NFS. The server was 2-3 seconds ahead of the client > (for some reason ntp wasn't running), but I wouldn't expect such chaos > to ensue from this? No, that won't matter. git shouldn't ever look at the current time (well, except when it creates a new commit object, of course), just the normal file time, which will be determined by the server. > Hmm. git status shows a ton of modified files, that I know I've never touched. > (arch/frv is somewhere I'd rather not venture) Sounds like you might have had a partial merge at some point that you ^C'd or that just failed, and you did "git reset" on it without the "--hard" flag? > Spooky. I'm seriously questioning myself whether or not I have > done something to this tree, but I'm 99.999% sure it's unmodified > (by me at least). > > git diff on any of the modified files shows no output, which > could be explained by your modified timestamp theory, but > how about the deleted/new files ? Those really are different in the working tree than the index (or the git tree: the difference between "git diff" and "git diff HEAD" - and "git status" does both - is obviously what you compare to). Since it's in the "will commit" section, it means that it's in your index but not in your HEAD tree. Which in turn implies that your index seems to not actually match your HEAD. That, in turn, is usually due to an aborted merge. Do a "git checkout -f". Linus - : 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