Eunsuk Kang <> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at
  • git rm bug? Eunsuk Kang
    • Re: git rm bug? Junio C Hamano

Reply via email to