git rm bug?

git rm bug?

[Eunsuk Kang]

Hello,

My understanding was that running "git rm" on a file will delete all ancestors of the file that are empty directories from the file system. I've ran into a case that seems a little strange.

To reproduce (using version 1.8.4.1 on Mac OS X 10.7.5):

git init
mkdir a
mkdir b
touch a/b/c.txt
git add .
git commit

Then, running the commands

$ rm a/b/c.txt
$ git rm a/b/c.txt

deletes "c.txt" as well as both directories "a" and "b", as expected. But if I instead do

$ rm -r a/b
$ git rm a/b/c.txt

then git deletes "c.txt" and "b", but leaves "a" intact in the file system. Is this a bug?

Thank you,
Eunsuk

Re: git rm bug?

[Junio C Hamano]

Eunsuk Kang <eskang@csail.mit.edu> writes:

> My understanding was that running "git rm" on a file will delete
> all ancestors of the file that are empty directories from the file
> system.

Not really.

We do recurse up to see if a/b/ and then a/ has become a useless
empty directory when we did remove a/b/c from the working tree, but
when we did not have to remove a/b/c (because you have already
removed it), we assume that you know what you are doing and do
nothing to the leading directories.

This behaviour is not because we suspect that you might want to
retain a/ or a/b/; it is just we do not even bother.  So it is
entirely plausible that a patch to actually bother checking the
leading directories to see if they have become or they already were
empty directories and remove them, if done cleanly, may be a welcome
change. At least, that would make things consistent between the
cases where you have already manually removed the file a/b/c on the
working tree and where the command removed in response to your
direct request to remove the same file a/b/c.