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

Carl Worth <cworth@cworth.org> 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 --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.

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.  :-)

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