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