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

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 --version
	git version 1.2.0.gf6e8
	$ git init-db
	defaulting to local storage area
	$ touch file; git add file; git commit -m "Add file"
	Committing initial tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078
	$ git tag OLD
	$ mkdir -p a/b/c; touch a/b/c/foo; git add a/b/c/foo; git commit -m
	"Add foo"
	$ git checkout -b bogus
	$ git reset --hard OLD
	$ find a
	a
	a/b
	a/b/c
	$

Is this operator error? I don't see any extra options I might be missing in the documentation of git-reset.

I haven't looked into the implementation at all yet to see what might be going on.

-Carl

Carl Worth <cworth@cworth.org> wrote:

Its not operator error.

I just dug though git-reset.sh in 1.2.0 and it won't cull directories, only files. Culling the directories is a little bit on the ugly side obviously as you must cull bottom-up. The perl code which git-reset.sh is using to cull files definately won't cull the directories.

No patch attached. Maybe someone not on the east coast can write one; I need to go catch some sleep. :-)

Carl Worth <cworth@cworth.org> writes:

Git does not track directories but bends backwards to make empty directories go away. I do not know if it is an operator error or not, but it appears sometimes it does not bend hard enough.

Interestingly enough, this seems to do things more carefully.

	$ ...
	$ git commit -m 'Add file'
        $ git branch OLD
        $ ...
        $ git commit -m 'Add a/b/c/foo'
        $ git checkout -b bogo
        $ git checkout OLD

On Tue, 14 Feb 2006, Carl Worth wrote:

"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