On Wed, 15 Oct 2008, Andrew Morton wrote:
quoted text
> 
> I treat my git directory as a read-only thing.  I only ever modify it
> with git commands.

Ok. 

quoted text
> > (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
--
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