Re: Untracked working tree files

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Oct 15, 2008, 19:31 UTC
Message-ID: <alpine.LFD.2.00.0810151219120.3288@nehalem.linux-foundation.org>
In-Reply-To: <alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm>

On Wed, 15 Oct 2008, david@lang.hm wrote:

> 
> the fact that git will happily leave modified things in the working directory
> appears to be very helpful for some developers, but it's also a big land mine
> for others.

Hmm. It doesn't actually do that normally. If you switch between trees, git will (or _should_) remove the old files that it knows about. If you get a lot of left-over turds, there's something wrong.

It could be a git bug, of course. That said, especially considering the source of this, I wonder if it's just that Andrew ends up using all those non-git scripts on top of a git tree, and then that can result in git *not* knowing about a certain file, and then when switching between trees (with either git checkout or with git reset), the data that was created with non-git tools gets left behind and now git will be afraid to overwrite it.

So yes, there are ways to force it (both "git checkout -f" and "git reset --hard" having already been mentioned), but the need for that - especially if it's common - is a bit discouraging.

Especially since it's still possible that it's some particular mode of git usage that leaves those things around. Andrew - have you any clue what it is that triggers the behavior?

(By the filename, I realize it's a file that doesn't exist in one tree or the other, and which doesn't get removed at some point. But have you had merge failures, for example? Is it perhaps a file that was created during a non-clean merge, and then got left behind due to the merge being aborted? It would be interesting to know what led up to this..)

			Linus