Re: "git reset --hard" leaves empty directories that shouldn't exist

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 14 Feb 2006, Carl Worth wrote:
>
> I've been exploring the potential for git-sync, and I found some odd
> behavior with "git reset --hard". It appears that if the current tree
> has some directory structure (at least two levels deep) that does not
> exist in the tree being reset to, that empty directories are left
> around after the reset:

"git reset --hard xyz" in many ways is a sledgehammer, and it says "I want 
the state at the point of xyz, and I don't care _what_ the heck the 
current state is".

Now, that's somewhat problematic, exactly because of that "screw the 
current state" thing. It actually tries to remove files (see the 
"tmp-exists" thing in the git-reset script), but it's being pretty stupid 
about it. It also very definitely will not try to remove subdirectories, 
empty or not.

(I say that without being able to read perl, so I might be wrong. Maybe it 
tries and just fails).

Anyway, if you want to do the "gentle and smart" thing, you should 
probably actually use

	git-read-tree -m -u <oldtree> <newtree>

which unlike "git-reset" will gently _update_ the tree from one version to 
another (and will error out if your checked-out copy doesn't match the 
old tree).

And the gentle way will actually do the right thing wrt subdirectories 
(note that it will _not_ remove empty subdirectories if you have left 
files - like object files - around that it doesn't know about: that's not 
an error, but the unknown file will not, nor the subdirectory, be 
removed).

And yes, git-reset should probably do the subdirectory thing too. In the 
meantime you should think of it as the brute-force and not very smart way 
(in Calvin and Hobbes terms, "git reset" is Moe).

			Linus