Re: merging problems with Linus' kernel tree.

[Linus Torvalds <torvalds@osdl.org>]

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