{"thread":{"id":"43136","subject":"Re: On removing files and \"git-rm is pointless\"","startedAt":"2006-12-02T17:05:16Z","lastAt":"2006-12-05T05:43:15Z","messageCount":13,"participants":["Linus Torvalds","Olivier Galibert","Nicolas Pitre","Carl Worth","Junio C Hamano","Sam Vilain","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296393","messageId":"87odqm2ppv.wl%cworth@cworth.org","threadId":"43136","inReplyTo":null,"subject":"On removing files and \"git-rm is pointless\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-02T17:05:16Z","receivedAt":"2006-12-02T17:05:16Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"Some people have recently asked questions about why we even have a\n\"git rm\" command since it seems so pointless if you understand git's\nmodel and \"commit -a\" well enough.\n\nI wrote that command, so let me explain.\n\nThe problem I was trying to address is that a new user (me), was\ntrying to learn git and made it through a scenario like this:\n\n\tgit init-db\n\techo a > a\n\tgit add a\n\tgit commit\n\n\t\"Cool, that works. Now let's explore file deletion:\"\n\n\trm file\n\tgit commit\n\n\t\"Hmm... that' didn't work, and git commit says:\n\n\t\t# (use git-update-index to mark for commit)\n\t\t#\n\t\t# deleted: file\n\n\tI explored the documentation and found\n\t\"git update-index --remove file\" and thought, \"this git system\n\tis insane! what a horrible command line that is!\"\n\nSo, with \"git commit\", it doesn't work to just plain delete the file.\n\nNow, a really cool thing about git and something that makes it easier\nthan other systems, (like cvs say), is that you don't _have_ to do\nanything extra to tell it about file deletion, (nor file rename). But\nto get the cool feature to work, you have to use \"commit -a\":\n\n\trm file\n\tgit commit -a\n\nIs our new documentation going to lead users to discover this great\nfeature? We're talking about documenting \"commit -a\" as, \"'add' all\ntracked files then commit\". It would take an exceptional stretch for a\nnew reader to take that sentence and realize that it would also mean\nthat any deleted file would also be removed from git's tracking. We're\nusing a verb with the _opposite_ meaning for crying out loud!\n\nSo, back to \"git rm\". I added it not just because some people might be\ntrained to tell the SCM about file removal. I added it to make \"git\ncommit\" seem more reliable, (since it can feel broken to new\nusers---it doesn't seem 'smart' enough to just figure out what changes\nhave been made to files that are being tracked).\n\nSo we should show the \"smarter\" behavior to users by default. Then\n\"git commit\" wouldn't feel broken. We could even throw away \"git rm\"\nand use its absence as a selling point for git. \"Hey, git's actually\n_easier_ to use than that broken stuff you've been using.\"\n\nWouldn't that be great?\n\n-Carl\n\n\n\n"},{"id":"293900","messageId":"Pine.LNX.4.64.0612020919400.3476@woody.osdl.org","threadId":"43136","inReplyTo":"87odqm2ppv.wl%cworth@cworth.org","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-02T17:37:03Z","receivedAt":"2006-12-02T17:37:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 2 Dec 2006, Carl Worth wrote:\n>\n> Some people have recently asked questions about why we even have a\n> \"git rm\" command since it seems so pointless if you understand git's\n> model and \"commit -a\" well enough.\n\nI have to admit that I'm not a big fan of \"git rm\".\n\nI'd like it more if it defaulted to actually removing the file, preferably \nrefusing to with an error message if the file didn't match the index. And \nthen use \"git rm -f\" to force-remove a dirty file.\n\nAs it is, because I just find \"git rm\" to be annoying, I simply do what \nyou talk about:\n\n> \trm file\n> \tgit commit -a\n\nWorks fine for me, and is more natural than \"git rm\" at least in my mind.\n\n> Is our new documentation going to lead users to discover this great\n> feature?\n\nI definitely wouldn't object at all. The _best_ of both worlds would be \nto:\n\n - document how git will detect changes to files it knows about \n (_including_ removal) automatically with \"git commit -a\", and make it \n clear that \"git rm\" thus isn't really needed.\n\n - but because it makes sense to have the mirror symmetry of \"git add\" and \n \"git rm\", and because people expect to be able to do \"git rm\" from \n other systems anyway, just keep the command around, and possibly make \n the default behaviour a bit more obvious.\n\nOn \"git rm\", I'd suggest:\n\n - with no flags: remove the working file too, but _only_ if it matches \n the index. NOTE! This is a change in semantics, but damn, if people \n have found \"git add\" hard to understand, I think \"git rm\" is much \n worse, and doesn't even match \"git mv\" (whcih _does_ move the working \n file, and doesn't just do a in-index move)\n\n - with \"-f\": do what \"git rm -f\" does now. Just force the thing. Don't \n care whether the file is dirty in the working tree or whether it even \n exists in the index. Just get rid of it already, both in the index \n (regardless of state or whether it is there at all) _and_ in the \n working tree (again, regardless of state)\n\nOne thing to look out for: \"git rm\" actually defaults to the recursive \nbehaviour, something that might take people by surprise. If you give it a \ndirectory name, it will happily delete all tracked files from within that \ndirectory, even without \"-r\". That is probably a design mistake. So it \nwould probably make sense to:\n\n - without \"-r\", don't do the partial matches at the beginning (but still \n do globbing matches, of course, so \"git rm dir/*\" wouldn't need an \n \"-r\", but \"git rm -r dir/\", which does the same thing, _would_ need an \n \"-r\" to be effective)\n\nFinal note: arguably, the current \"git rm\" is a better mirror image of \n\"git add\" than what I suggest above. \"git add\" doesn't actually create the \nworking file (you had to do that yourself), so you _could_ argue that \"git \nrm\" as it stands now is closer to the \"reverse\" of git add. The same is \ntrue of the recursive behaviour.\n\nHowever, I'd argue that:\n\n - \"rm\" isn't the reverse of \"add\" in the first place. If we had a \"git \n subtract\" file, _that_ would be the reverse of \"git add\" ;)\n\n - \"rm\" isn't the reverse of \"add\" in another sense: \"rm\" is just more \n dangerous. So not having the mirror-image semantics makes sense simply \n becaue the dangerousness of the commands aren't mirror images.\n\nAnyway, I don't personally much care. As mentioned, I'll happily just \nremove the file and do \"git commit -a\" instead (or, indeed, if I want to \nplay with the index, I'm perfectly comfy just doing \"git update-index\" \nwith \"--force-remove\" or something - but clearly I'm more confy with the \nindex and it's strangly named commands than most ;^).\n\n"},{"id":"295724","messageId":"4571DB40.6020800@vilain.net","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612020919400.3476@woody.osdl.org","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-12-02T20:00:00Z","receivedAt":"2006-12-02T20:00:00Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> I'd like it more if it defaulted to actually removing the file, preferably \n> refusing to with an error message if the file didn't match the index. \n\nindex, or HEAD version? Otherwise you can \"update-index\"; \"rm\" without\nseeing something wrong is happening.\n\n> Final note: arguably, the current \"git rm\" is a better mirror image of \n> \"git add\" than what I suggest above. \"git add\" doesn't actually create the \n> working file (you had to do that yourself), so you _could_ argue that \"git \n> rm\" as it stands now is closer to the \"reverse\" of git add. The same is \n> true of the recursive behaviour.\n\nFor this reason I think that the current behaviour is not so broken.\nEverywhere else, it is up to the user to make the changes to the working\ncopy that they want to commit. I like git-rm because I can go:\n\n rm -rf whatever\n git-rm whatever\n\nI can see why you'd want\n\n git-rm -u whatever\n\nor\n\n rm -rf whatever\n git-commit -a\n\nAn extra flag to actually unlink the files is less likely to cause bugs\nwith porcelain expecting git-rm to behave as it does currently. If it\nis to be changed in backwards incompatible ways, there should probably\nbe a deprecation time.\n\n\"rm -u\" could alter the default semantics, ie, require the extra -r\noption to recurse and require -f unless things are safe.\n\n"},{"id":"294400","messageId":"Pine.LNX.4.64.0612022246310.2630@xanadu.home","threadId":"43136","inReplyTo":"4571DB40.6020800@vilain.net","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-03T03:50:46Z","receivedAt":"2006-12-03T03:50:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 3 Dec 2006, Sam Vilain wrote:\n\n> Linus Torvalds wrote:\n> > I'd like it more if it defaulted to actually removing the file, preferably \n> > refusing to with an error message if the file didn't match the index. \n> \n> index, or HEAD version? Otherwise you can \"update-index\"; \"rm\" without\n> seeing something wrong is happening.\n\nWell tough then.\n\nI think what Linus is proposing makes tons of sense.\n\nIf you do git rm by mistake then you can always do git checkout on that \nfile to get it back.\n\nIf you modified it so it doesn't match the index then git rm won't do \nanything by default so you have a chance to think a bit more.\n\nIf you updated the index, didn't commit anything but then do git rm then \nyou certainly wanted to really rm the file.\n\nIf not then just feel the pain of your stupidity and start again from \nthe latest version.\n\n\n"},{"id":"294737","messageId":"7vd570q888.fsf@assigned-by-dhcp.cox.net","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612022246310.2630@xanadu.home","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-04T10:13:43Z","receivedAt":"2006-12-04T10:13:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> I think what Linus is proposing makes tons of sense.\n>\n> If you do git rm by mistake then you can always do git checkout on that\n> file to get it back.\n>\n> If you modified it so it doesn't match the index then git rm won't do\n> anything by default so you have a chance to think a bit more.\n>\n> If you updated the index, didn't commit anything but then do git rm then\n> you certainly wanted to really rm the file.\n\nFWIW, I too am in favor of the proposed fix to \"git rm\" as Linus\noutlined.\n"},{"id":"295957","messageId":"el0uaf$n7h$1@sea.gmane.org","threadId":"43136","inReplyTo":"7vd570q888.fsf@assigned-by-dhcp.cox.net","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-04T10:48:42Z","receivedAt":"2006-12-04T10:48:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n>> I think what Linus is proposing makes tons of sense.\n>>\n>> If you do git rm by mistake then you can always do git checkout on that\n>> file to get it back.\n>>\n>> If you modified it so it doesn't match the index then git rm won't do\n>> anything by default so you have a chance to think a bit more.\n>>\n>> If you updated the index, didn't commit anything but then do git rm then\n>> you certainly wanted to really rm the file.\n> \n> FWIW, I too am in favor of the proposed fix to \"git rm\" as Linus\n> outlined.\n\n+1. I'm also for this change. Of course if the working area version doesn't\nmatch HEAD version git-rm should remove only index entry, and print warning\nmessage, for example what it does now, i.e.\n rm ''\nor if we want more chatty version (core.gitgor = true) it would print:\n File '' changed. Use \"rm ''\" to remove.\n(or something like that).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295265","messageId":"Pine.LNX.4.64.0612040737120.3476@woody.osdl.org","threadId":"43136","inReplyTo":"7vd570q888.fsf@assigned-by-dhcp.cox.net","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-04T15:42:26Z","receivedAt":"2006-12-04T15:42:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Dec 2006, Junio C Hamano wrote:\n> \n> FWIW, I too am in favor of the proposed fix to \"git rm\" as Linus\n> outlined.\n\nNote that somebody (sorry, forget who) correctly pointed out that in order \nto be \"safe\", the file that you \"rm\" has to match not only the index, but \nit should match the HEAD tree too.\n\nIf it matches both the index and the HEAD tree, a \"git rm filename\" is \ntotally safe, since you can always get it back by just doing a\n\n\tgit checkout HEAD filename\n\nso the \"git rm\" really didn't lose any info, and as such, we can _happily_ \nremove the working tree copy without any concern at all.\n\nIf it doesn't match HEAD, we can't get it back as easily, so maybe that's \nthe case when we want to have \"git rm -f filename\".\n\n(And obviously, for all the normal reasons, if the index or HEAD doesn't \nmatch, the error message should be helpful and also explicitly mention the \n\"-f\" flag. Somehing like\n\n\tfile 'x' does not match HEAD or has been staged for changes.\n\tWill not remove. Use '-f' to force removal.\n\n(\"has been staged for changes\" is just a long way of saying \"index\". See? \nI _can_ learn.)\n\n"},{"id":"295885","messageId":"el1go7$2ro$1@sea.gmane.org","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612040737120.3476@woody.osdl.org","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-04T16:03:07Z","receivedAt":"2006-12-04T16:03:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> (And obviously, for all the normal reasons, if the index or HEAD doesn't \n> match, the error message should be helpful and also explicitly mention the \n> \"-f\" flag. Somehing like\n> \n>         file 'x' does not match HEAD or has been staged for changes.\n>         Will not remove. Use '-f' to force removal.\n> \n> (\"has been staged for changes\" is just a long way of saying \"index\". See? \n> I _can_ learn.)\n\nI'd rather have\n\n File 'x' does not match HEAD or index (has been staged for changes).\n Will not remove. Use \"git rm -f 'x'\" to force removal.\n\nI'd rather not learn that \"staged for changes\" mean \"index\". I'm quote\ncomfortable with the concept of \"index\" and the name \"index\",\nthankyouverymuch.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294397","messageId":"20061204160429.GA8512@dspnet.fr.eu.org","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612040737120.3476@woody.osdl.org","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-12-04T16:04:29Z","receivedAt":"2006-12-04T16:04:29Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"\n\nOn Mon, Dec 04, 2006 at 07:42:26AM -0800, Linus Torvalds wrote:\n> (And obviously, for all the normal reasons, if the index or HEAD doesn't \n> match, the error message should be helpful and also explicitly mention the \n> \"-f\" flag. Somehing like\n> \n> \tfile 'x' does not match HEAD or has been staged for changes.\n> \tWill not remove. Use '-f' to force removal.\n\nAnd you wouldn't tell which, you stupid computer?\n\nI hate when error messages go \"there is a problem that may be x, y or\nz. You can figure out which one yourself.\".\n\nIncidentally, splitting the message would allow you to add a \"use git\ndiff x\" or a \"use git diff --cached x to see the differences\" message.\n\n\n\n"},{"id":"294920","messageId":"7v8xhnm9o6.fsf@assigned-by-dhcp.cox.net","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612040737120.3476@woody.osdl.org","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T01:08:25Z","receivedAt":"2006-12-05T01:08:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> If it doesn't match HEAD, we can't get it back as easily, so maybe that's \n> the case when we want to have \"git rm -f filename\".\n\nHmph. Wouldn't this lossage the same as the lossage we are\nremoving the \"safety valve\" for, when \"commit --only\" jumps the\nindex?\n"},{"id":"298145","messageId":"Pine.LNX.4.64.0612042225220.2630@xanadu.home","threadId":"43136","inReplyTo":"7v8xhnm9o6.fsf@assigned-by-dhcp.cox.net","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-05T03:29:13Z","receivedAt":"2006-12-05T03:29:13Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 4 Dec 2006, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > If it doesn't match HEAD, we can't get it back as easily, so maybe that's \n> > the case when we want to have \"git rm -f filename\".\n> \n> Hmph. Wouldn't this lossage the same as the lossage we are\n> removing the \"safety valve\" for, when \"commit --only\" jumps the\n> index?\n\nLosing an intermediate file state is much less severe than losing the \nlatest file state I would think.\n\n\n"},{"id":"294479","messageId":"87u00b0zx9.wl%cworth@cworth.org","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612042225220.2630@xanadu.home","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-05T03:44:34Z","receivedAt":"2006-12-05T03:44:34Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 04 Dec 2006 22:29:13 -0500 (EST), Nicolas Pitre wrote:\n> On Mon, 4 Dec 2006, Junio C Hamano wrote:\n> > Hmph. Wouldn't this lossage the same as the lossage we are\n> > removing the \"safety valve\" for, when \"commit --only\" jumps the\n> > index?\n>\n> Losing an intermediate file state is much less severe than losing the\n> latest file state I would think.\n\nOr, in fact, the _only_ state, (if using git-rm to \"undo\" a git-add of\na new file, for instance).\n\nAnd as for \"jumping\" the intermediate state without the safety valve\nof \"git commit files...\" I'm waiting to hear what Junio has to say\nabout my \"two conceptually distinct commit commands\" proposal which\nwould provide a way to avoid that, (the user just indicates whether\nit's index content or working-tree content that is to be committed).\n\n-Carl\n"},{"id":"296891","messageId":"7vslfukido.fsf@assigned-by-dhcp.cox.net","threadId":"43136","inReplyTo":"Pine.LNX.4.64.0612042225220.2630@xanadu.home","subject":"Re: On removing files and \"git-rm is pointless\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T05:43:15Z","receivedAt":"2006-12-05T05:43:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 4 Dec 2006, Junio C Hamano wrote:\n>\n>> Linus Torvalds writes:\n>> \n>> > If it doesn't match HEAD, we can't get it back as easily, so maybe that's \n>> > the case when we want to have \"git rm -f filename\".\n>> \n>> Hmph. Wouldn't this lossage the same as the lossage we are\n>> removing the \"safety valve\" for, when \"commit --only\" jumps the\n>> index?\n>\n> Losing an intermediate file state is much less severe than losing the \n> latest file state I would think.\n\nVery true indeed.\n"}]}