Re: "git reset --hard" leaves empty directories that shouldn't exist
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Feb 15, 2006, 08:06 UTC
- Message-ID
- <20060215080624.GA27037@spearce.org>
- In-Reply-To
- <87y80dhxfd.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
Show 25 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? 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.