Re: Untracked working tree files

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Oct 15, 2008, 20:08 UTC
Message-ID: <alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org>
In-Reply-To: <20081015124949.b657a8db.akpm@linux-foundation.org>

On Wed, 15 Oct 2008, Andrew Morton wrote:

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

Ok.

Show 10 quoted lines

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

Is "git checkout -f" part of the scripting? Or "git reset --hard"?

So what I could imagine is happening is:

 - you have a lot of automated merging

 - a merge goes south with a data conflict, and since it's all automated, 
   you just want to throw it away. So you do "git reset --force" to do 
   that.

 - but what "git reset --hard" means is to basically ignore all error 
   cases, including any unmerged entries that it just basically ignores.

 - so it did set the tree back, but the whole point of "--hard" is that it 
   ignores error cases, and doesn't really touch them.

Now, I don't think we ever really deeply thought about what the error cases should do when they are ignored. Should the file that is in some state we don't like be removed? Or should we just ignore the error and return without removing the file? Generally git tries to avoid touching things it doesn't understand, but I do think this may explain some pain for you, and it may not be the right thing in this case.

(And when I say "this case", I don't really know whether you use "git checkout -f" or "git reset --hard" or something else, so I'm not even going to say I'm sure exactly _which_ case "this case" actually us :)

Of course, the cheesy way for you to fix this may be to just add a

	git clean -dqfx

to directly after whatever point where you decide to reset and revert to an earlier stage. That just says "force remove all files I don't know about, including any I might ignore". IOW, "git reset --hard" will guarantee that all _tracked_ files are reset, but if you worry about some other crud that could have happened due to a failed merge, that additional "git clean" may be called for.

Of course, it's going to read the whole directory tree and that's not really cheap, but especially if you only do this for error cases, it's probably not going to be any worse. And I'm assuming you're not compiling in that tree, so you probably don't want to save object files (you can remove the "x" part, but then you could still at least in theory get a filename clash with something that is ignored and thus didn't get cleaned up).

			Linus