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

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

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Shawn Pearce]

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.

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

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> 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

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

[Linus Torvalds]

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