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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 15, 2006, 08:09 UTC
Message-ID: <7vk6bxm4be.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87y80dhxfd.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 24 quoted lines

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

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