Eunsuk Kang <esk...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
