git rm bug?

Eunsuk Kang· Oct 30, 2013, 05:23 UTC · lore

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

Junio C Hamano· Oct 30, 2013, 19:01 UTC · re: Eunsuk Kang · lore

Re: git rm bug?

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.