{"thread":{"id":"48664","subject":"git rm bug","startedAt":"2018-06-06T19:32:41Z","lastAt":"2018-06-06T22:51:21Z","messageCount":11,"participants":["Thomas Fischer","Robert P. J. Day","Duy Nguyen","Todd Zullinger","Jeff King","Timothy Rice","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"349546","messageId":"1528313557.2662346.1398855328.3E0F8023@webmail.messagingengine.com","threadId":"48664","inReplyTo":null,"subject":"git rm bug","fromName":"Thomas Fischer","fromEmail":"thomasfischer@fastmail.com","sentAt":"2018-06-06T19:32:37Z","receivedAt":"2018-06-06T19:32:41Z","isPatch":false,"sender":{"key":"thomasfischer@fastmail.com","avatar":null},"body":"OVERVIEW\n\n\"git rm\" will remove more files than specified. This is either a bug or undocumented behavior (not in the man pages).\n\nSETUP\n\n1. In a git repository, create an empty directory OR a chain of empty directories\n\n$ mkdir -p path/to/some/\n\n2. Create a file in the deepest directory and add it to tracking\n\n$ touch path/to/some/file\n$ git add path/to/some/file\n$ git commit -m 'add path/to/some/file'\n\nTHE BUG\n\nRun 'git rm' on the tracked file. \n\nEXPECTED BEHAVIOR\n\n$ git rm path/to/some/file\nrm 'path/to/some/file'\n$ ls path\nto/\n$ ls path/to\nsome/\n\nNote that path/, path/to/, and path/to/some/ still exist.\n\nACTUAL BEHAVIOR\n\n$ git rm path/to/some/file\nrm 'path/to/some/file'\n$ ls path\nls: cannot access 'path': No such file or directory\n\nThe entire chain of empty directories is removed, despite the fact the git outputs only \"rm 'path/to/some/file'\".\n\nThis ONLY occurs when all the directories in the chain are empty after the tracked file has been removed.\n\nThis behavior is NOT documented in the man pages.\n\nI propose that 'rmdir' statements are added to 'git rm' output, or that the man pages be updated to reflect this behavior.\n\nBest,\nThomas Fischer\n"},{"id":"349547","messageId":"alpine.LFD.2.21.1806061532420.9259@localhost.localdomain","threadId":"48664","inReplyTo":"1528313557.2662346.1398855328.3E0F8023@webmail.messagingengine.com","subject":"Re: git rm bug","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-06-06T19:33:27Z","receivedAt":"2018-06-06T19:35:47Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Wed, 6 Jun 2018, Thomas Fischer wrote:\n\n> OVERVIEW\n>\n> \"git rm\" will remove more files than specified. This is either a bug or undocumented behavior (not in the man pages).\n>\n> SETUP\n>\n> 1. In a git repository, create an empty directory OR a chain of empty directories\n>\n> $ mkdir -p path/to/some/\n>\n> 2. Create a file in the deepest directory and add it to tracking\n>\n> $ touch path/to/some/file\n> $ git add path/to/some/file\n> $ git commit -m 'add path/to/some/file'\n>\n> THE BUG\n>\n> Run 'git rm' on the tracked file.\n>\n> EXPECTED BEHAVIOR\n>\n> $ git rm path/to/some/file\n> rm 'path/to/some/file'\n> $ ls path\n> to/\n> $ ls path/to\n> some/\n>\n> Note that path/, path/to/, and path/to/some/ still exist.\n>\n> ACTUAL BEHAVIOR\n>\n> $ git rm path/to/some/file\n> rm 'path/to/some/file'\n> $ ls path\n> ls: cannot access 'path': No such file or directory\n>\n> The entire chain of empty directories is removed, despite the fact\n> the git outputs only \"rm 'path/to/some/file'\".\n\n git cannot track empty directories. as that was the *only* content\nin that whole hierarchy, the entire hierarchy had to be deleted.\n\nrday\n"},{"id":"349549","messageId":"1528314421.2665575.1398886712.579F37CE@webmail.messagingengine.com","threadId":"48664","inReplyTo":"alpine.LFD.2.21.1806061532420.9259@localhost.localdomain","subject":"Re: git rm bug","fromName":"Thomas Fischer","fromEmail":"thomasfischer@fastmail.com","sentAt":"2018-06-06T19:47:01Z","receivedAt":"2018-06-06T19:47:04Z","isPatch":false,"sender":{"key":"thomasfischer@fastmail.com","avatar":null},"body":"I agree that the entire chain of empty directories should not be tracked, as git tracks content, not files.\n\nHowever, when I run 'rm path/to/some/file', I expect path/to/some/ to still exist.\n\nSimilarly, when I run 'git rm path/to/some/file', I expect path/to/some/ to exist, *albeit untracked*.\n\nI do NOT expect git to *track* empty directories. But I also do NOT expect it to remove untracked directories.\n\n-- \n Thomas Fischer\n thomasfischer@fastmail.com\n\nOn Wed, Jun 6, 2018, at 2:33 PM, Robert P. J. Day wrote:\n> On Wed, 6 Jun 2018, Thomas Fischer wrote:\n> \n> > OVERVIEW\n> >\n> > \"git rm\" will remove more files than specified. This is either a bug or undocumented behavior (not in the man pages).\n> >\n> > SETUP\n> >\n> > 1. In a git repository, create an empty directory OR a chain of empty directories\n> >\n> > $ mkdir -p path/to/some/\n> >\n> > 2. Create a file in the deepest directory and add it to tracking\n> >\n> > $ touch path/to/some/file\n> > $ git add path/to/some/file\n> > $ git commit -m 'add path/to/some/file'\n> >\n> > THE BUG\n> >\n> > Run 'git rm' on the tracked file.\n> >\n> > EXPECTED BEHAVIOR\n> >\n> > $ git rm path/to/some/file\n> > rm 'path/to/some/file'\n> > $ ls path\n> > to/\n> > $ ls path/to\n> > some/\n> >\n> > Note that path/, path/to/, and path/to/some/ still exist.\n> >\n> > ACTUAL BEHAVIOR\n> >\n> > $ git rm path/to/some/file\n> > rm 'path/to/some/file'\n> > $ ls path\n> > ls: cannot access 'path': No such file or directory\n> >\n> > The entire chain of empty directories is removed, despite the fact\n> > the git outputs only \"rm 'path/to/some/file'\".\n> \n> git cannot track empty directories. as that was the *only* content\n> in that whole hierarchy, the entire hierarchy had to be deleted.\n> \n> rday\n"},{"id":"349550","messageId":"alpine.LFD.2.21.1806061550530.9562@localhost.localdomain","threadId":"48664","inReplyTo":"1528314421.2665575.1398886712.579F37CE@webmail.messagingengine.com","subject":"Re: git rm bug","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-06-06T19:51:54Z","receivedAt":"2018-06-06T19:54:13Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Wed, 6 Jun 2018, Thomas Fischer wrote:\n\n> I agree that the entire chain of empty directories should not be\n> tracked, as git tracks content, not files.\n>\n> However, when I run 'rm path/to/some/file', I expect path/to/some/\n> to still exist.\n\n why?\n\n> Similarly, when I run 'git rm path/to/some/file', I expect\n> path/to/some/ to exist, *albeit untracked*.\n\n again, why?\n\n> I do NOT expect git to *track* empty directories. But I also do NOT\n> expect it to remove untracked directories.\n\n why not?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca/dokuwiki\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"349551","messageId":"CACsJy8CpsF8rtiJVtLK4d=7RdtPBy5QRy7XURFvpaWtQCynJkA@mail.gmail.com","threadId":"48664","inReplyTo":"1528313557.2662346.1398855328.3E0F8023@webmail.messagingengine.com","subject":"Re: git rm bug","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-06-06T19:54:03Z","receivedAt":"2018-06-06T19:54:37Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jun 6, 2018 at 9:32 PM, Thomas Fischer\n wrote:\n> OVERVIEW\n>\n> \"git rm\" will remove more files than specified. This is either a bug or undocumented behavior (not in the man pages).\n\nThe behavior is intended, with a question mark. This change is\nintroduced in d9b814cc97 (Add builtin \"git rm\" command - 2006-05-19).\nI quote the relevant paragraph from that commit\n\n The other question is what to do with leading directories. The old \"git\n rm\" script didn't do anything, which is somewhat inconsistent. This one\n will actually clean up directories that have become empty as a result of\n removing the last file, but maybe we want to have a flag to decide the\n behaviour?\n\nTo me we definitely should document this (patches welcome!) then maybe\nrevisit this \"have a flag to decide the behavior\" question from 12\nyears ago.\n\n> SETUP\n>\n> 1. In a git repository, create an empty directory OR a chain of empty directories\n>\n> $ mkdir -p path/to/some/\n>\n> 2. Create a file in the deepest directory and add it to tracking\n>\n> $ touch path/to/some/file\n> $ git add path/to/some/file\n> $ git commit -m 'add path/to/some/file'\n>\n> THE BUG\n>\n> Run 'git rm' on the tracked file.\n>\n> EXPECTED BEHAVIOR\n>\n> $ git rm path/to/some/file\n> rm 'path/to/some/file'\n> $ ls path\n> to/\n> $ ls path/to\n> some/\n>\n> Note that path/, path/to/, and path/to/some/ still exist.\n>\n> ACTUAL BEHAVIOR\n>\n> $ git rm path/to/some/file\n> rm 'path/to/some/file'\n> $ ls path\n> ls: cannot access 'path': No such file or directory\n>\n> The entire chain of empty directories is removed, despite the fact the git outputs only \"rm 'path/to/some/file'\".\n>\n> This ONLY occurs when all the directories in the chain are empty after the tracked file has been removed.\n>\n> This behavior is NOT documented in the man pages.\n>\n> I propose that 'rmdir' statements are added to 'git rm' output, or that the man pages be updated to reflect this behavior.\n>\n> Best,\n> Thomas Fischer\n\n\n\n-- \nDuy\n"},{"id":"349552","messageId":"20180606200137.GJ3094@zaya.teonanacatl.net","threadId":"48664","inReplyTo":"1528314421.2665575.1398886712.579F37CE@webmail.messagingengine.com","subject":"Re: git rm bug","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2018-06-06T20:01:38Z","receivedAt":"2018-06-06T20:01:43Z","isPatch":false,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Thomas Fischer wrote:\n> I agree that the entire chain of empty directories should not be tracked, as git tracks content, not files.\n> \n> However, when I run 'rm path/to/some/file', I expect path/to/some/ to still exist.\n> \n> Similarly, when I run 'git rm path/to/some/file', I expect path/to/some/ to exist, *albeit untracked*.\n> \n> I do NOT expect git to *track* empty directories. But I also do NOT expect it to remove untracked directories.\n\nIt looks like this behavior has been in place for many\nyears, since d9b814cc97 (\"Add builtin \"git rm\" command\",\n2006-05-19). Interestingly, Linus noted in the commit\nmessage that the removal of leading directories was\ndifferent than when git-rm was a shell script. And he\nwondered if it might be worth having an option to control\nthat behavior.\n\nI imagine that most users either want the current behavior\nor they rarely run across this and are surprised, given how\nlong git rm has worked this way.\n\nIt does seem like something which could be noted in the git\nrm docs. Perhaps you'd care to take a stab at a patch to\nadd a note to Documentation/git-rm.txt Thomas? Maybe a note\nat the end of the DISCUSSION section?\n\n-- \nTodd\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nIf everything seems to be going well, you have obviously overlooked\nsomething.\n\n"},{"id":"349553","messageId":"20180606201144.GA32098@sigill.intra.peff.net","threadId":"48664","inReplyTo":"20180606200137.GJ3094@zaya.teonanacatl.net","subject":"Re: git rm bug","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-06-06T20:11:44Z","receivedAt":"2018-06-06T20:11:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote:\n\n> Thomas Fischer wrote:\n> > I agree that the entire chain of empty directories should not be tracked, as git tracks content, not files.\n> > \n> > However, when I run 'rm path/to/some/file', I expect path/to/some/ to still exist.\n> > \n> > Similarly, when I run 'git rm path/to/some/file', I expect path/to/some/ to exist, *albeit untracked*.\n> > \n> > I do NOT expect git to *track* empty directories. But I also do NOT expect it to remove untracked directories.\n> \n> It looks like this behavior has been in place for many\n> years, since d9b814cc97 (\"Add builtin \"git rm\" command\",\n> 2006-05-19). Interestingly, Linus noted in the commit\n> message that the removal of leading directories was\n> different than when git-rm was a shell script. And he\n> wondered if it might be worth having an option to control\n> that behavior.\n> \n> I imagine that most users either want the current behavior\n> or they rarely run across this and are surprised, given how\n> long git rm has worked this way.\n\nIt's also consistent with other parts of Git that remove files. E.g.,\n\"git checkout\" to a state that does not have the file will remove the\nleading directories (if they're empty, of course).\n\n> It does seem like something which could be noted in the git\n> rm docs. Perhaps you'd care to take a stab at a patch to\n> add a note to Documentation/git-rm.txt Thomas? Maybe a note\n> at the end of the DISCUSSION section?\n\nYeah, agreed.\n\n-Peff\n"},{"id":"349554","messageId":"20180606201012.GA2454@sleipnir","threadId":"48664","inReplyTo":"20180606200137.GJ3094@zaya.teonanacatl.net","subject":"Re: git rm bug","fromName":"Timothy Rice","fromEmail":"timothy.rice@unimelb.edu.au","sentAt":"2018-06-06T20:10:13Z","receivedAt":"2018-06-06T20:17:05Z","isPatch":false,"sender":{"key":"timothy.rice@unimelb.edu.au","avatar":null},"body":"> It does seem like something which could be noted in the git\n> rm docs. Perhaps you'd care to take a stab at a patch to\n> add a note to Documentation/git-rm.txt Thomas? Maybe a note\n> at the end of the DISCUSSION section?\n\nThat same documentation could mention a common workaround for when someone\ndoes really want to keep the empty directories:\n\n$ touch ./path/to/empty/dir/.keep\n$ git add ./path/to/empty/dir/.keep\n$ git commit -m \"Keep that empty directory because it is needed for \"\n\nThis would obviate the need for a new flag to switch behaviours.\n\n~ Tim\n\n"},{"id":"349555","messageId":"alpine.LFD.2.21.1806061609440.10418@localhost.localdomain","threadId":"48664","inReplyTo":"20180606201012.GA2454@sleipnir","subject":"Re: git rm bug","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-06-06T20:20:09Z","receivedAt":"2018-06-06T20:22:31Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Thu, 7 Jun 2018, Timothy Rice wrote:\n\n> > It does seem like something which could be noted in the git\n> > rm docs. Perhaps you'd care to take a stab at a patch to\n> > add a note to Documentation/git-rm.txt Thomas? Maybe a note\n> > at the end of the DISCUSSION section?\n>\n> That same documentation could mention a common workaround for when\n> someone does really want to keep the empty directories:\n>\n> $ touch ./path/to/empty/dir/.keep\n> $ git add ./path/to/empty/dir/.keep\n> $ git commit -m \"Keep that empty directory because it is needed for \"\n>\n> This would obviate the need for a new flag to switch behaviours.\n\n i'm going to be contrarian and obstinate and suggest that the\ncurrent behaviour is fine, since there is no compelling rationale for\nany *other* behaviour.\n\n invariably, every defense for hanging on to empty directories boils\ndown to, \"i might do something in the future that expects those\ndirectories to exist.\" well, if that's the case, then create them when\nyou need them -- nothing you do should ever simply *assume* the\nexistence of essential directories.\n\n in addition, by \"untracking\" those directories, you're suggesting\nthat git quietly do what should normally be done by \"git rm --cached\".\nif i want that behaviour, i would prefer to have to type it myself.\n\n i'm fine with just adding a note to \"git rm\" making it clear what\nhappens in this case. i see no value in supporting extra options that\nsimply encourage bad behaviour.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca/dokuwiki\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"349572","messageId":"87bmcnzg0l.fsf@evledraar.gmail.com","threadId":"48664","inReplyTo":"1528314421.2665575.1398886712.579F37CE@webmail.messagingengine.com","subject":"Re: git rm bug","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-06-06T22:50:18Z","receivedAt":"2018-06-06T22:50:24Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jun 06 2018, Thomas Fischer wrote:\n\n> I agree that the entire chain of empty directories should not be\n> tracked, as git tracks content, not files.\n>\n> However, when I run 'rm path/to/some/file', I expect path/to/some/ to\n> still exist.\n>\n> Similarly, when I run 'git rm path/to/some/file', I expect\n> path/to/some/ to exist, *albeit untracked*.\n>\n> I do NOT expect git to *track* empty directories. But I also do NOT\n> expect it to remove untracked directories.\n\nOthers have said why, but here's an edge case you probably haven't\nthought of:\n\n (\n rm -rf /tmp/repo &&\n git init /tmp/repo &&\n cd /tmp/repo &&\n mkdir -p foo/bar/baz &&\n git status\n )\n\nIf you just have empty directories \"git status\" will report nothing,\nalthough \"git clean -dxfn\" will show what would be cleaned up.\n\nSo if this worked as you're suggesting then someone could 'git rm\" some\nfile, then everything would report that they're on commit XYZ, but if\nthey re-cloned at that commit they'd get a tree that would look\ndifferent.\n\nNo git command should behave in such a way as to leave the tree in a\nstate when moving from commit X->Y that you wouldn't get the same Y if\nyou re-cloned.\n"},{"id":"349573","messageId":"87a7s7zfz0.fsf@evledraar.gmail.com","threadId":"48664","inReplyTo":"20180606201012.GA2454@sleipnir","subject":"Re: git rm bug","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-06-06T22:51:15Z","receivedAt":"2018-06-06T22:51:21Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jun 06 2018, Timothy Rice wrote:\n\n>> It does seem like something which could be noted in the git\n>> rm docs. Perhaps you'd care to take a stab at a patch to\n>> add a note to Documentation/git-rm.txt Thomas? Maybe a note\n>> at the end of the DISCUSSION section?\n>\n> That same documentation could mention a common workaround for when someone\n> does really want to keep the empty directories:\n>\n> $ touch ./path/to/empty/dir/.keep\n> $ git add ./path/to/empty/dir/.keep\n> $ git commit -m \"Keep that empty directory because it is needed for \"\n\nnit: The .gitkeep convention seems to be much more common in the wild\nthan .keep, and it's probably time we documented that somewhere, even\nthough it's not a magic .git* file like .gitattributes et al.\n"}]}