Re: Untracked working tree files

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 15 Oct 2008 12:31:40 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> 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.

I treat my git directory as a read-only thing.  I only ever modify it
with git commands.

> 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?

Sorry, no, I haven't seen a pattern.

> (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..)

That's certainly a possibility - I get a lot of merge failures.  A real
lot.  And then quite a bit of rebasing goes on, especially in
linux-next.  And then there's all the other stuff which Stephen does on
top of the underlying trees to get something releasable happening.