{"thread":{"id":"35244","subject":"git rm bug?","startedAt":"2013-10-30T05:23:29Z","lastAt":"2013-10-30T19:01:12Z","messageCount":2,"participants":["Eunsuk Kang","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229778","messageId":"155154AA-15E8-49E8-8261-6295AC6F6CF7@csail.mit.edu","threadId":"35244","inReplyTo":null,"subject":"git rm bug?","fromName":"Eunsuk Kang","fromEmail":"eskang@csail.mit.edu","sentAt":"2013-10-30T05:23:29Z","receivedAt":"2013-10-30T05:23:29Z","isPatch":false,"sender":{"key":"eskang@csail.mit.edu","avatar":null},"body":"Hello,\n\nMy 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.\n\nTo reproduce (using version 1.8.4.1 on Mac OS X 10.7.5):\n\ngit init\nmkdir a\nmkdir b\ntouch a/b/c.txt\ngit add .\ngit commit\n\nThen, running the commands\n\n$ rm a/b/c.txt\n$ git rm a/b/c.txt\n\ndeletes \"c.txt\" as well as both directories \"a\" and \"b\", as expected. But if I instead do\n\n$ rm -r a/b\n$ git rm a/b/c.txt\n\nthen git deletes \"c.txt\" and \"b\", but leaves \"a\" intact in the file system. Is this a bug?\n\nThank you,\nEunsuk\n"},{"id":"229850","messageId":"xmqqob66bn2f.fsf@gitster.dls.corp.google.com","threadId":"35244","inReplyTo":"155154AA-15E8-49E8-8261-6295AC6F6CF7@csail.mit.edu","subject":"Re: git rm bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-30T19:01:12Z","receivedAt":"2013-10-30T19:01:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eunsuk Kang <eskang@csail.mit.edu> writes:\n\n> My understanding was that running \"git rm\" on a file will delete\n> all ancestors of the file that are empty directories from the file\n> system.\n\nNot really.\n\nWe do recurse up to see if a/b/ and then a/ has become a useless\nempty directory when we did remove a/b/c from the working tree, but\nwhen we did not have to remove a/b/c (because you have already\nremoved it), we assume that you know what you are doing and do\nnothing to the leading directories.\n\nThis behaviour is not because we suspect that you might want to\nretain a/ or a/b/; it is just we do not even bother.  So it is\nentirely plausible that a patch to actually bother checking the\nleading directories to see if they have become or they already were\nempty directories and remove them, if done cleanly, may be a welcome\nchange. At least, that would make things consistent between the\ncases where you have already manually removed the file a/b/c on the\nworking tree and where the command removed in response to your\ndirect request to remove the same file a/b/c.\n"}]}