{"thread":{"id":"51091","subject":"Is git-checkout's restoring d/f conflict really sane?","startedAt":"2019-05-14T09:41:51Z","lastAt":"2019-05-15T01:56:51Z","messageCount":4,"participants":["Duy Nguyen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"375488","messageId":"CACsJy8Bew3i6AL_XWfhLhCvdSFYVCGoEQepi9KLmSDPVmDu5Zg@mail.gmail.com","threadId":"51091","inReplyTo":null,"subject":"Is git-checkout's restoring d/f conflict really sane?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-05-14T09:41:23Z","receivedAt":"2019-05-14T09:41:51Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"$ echo data > one\n$ git add one\n$ rm one\n$ mkdir one\n$ echo two > one/two\n$ echo three > one/three\n$ git checkout one\n$ ls -l one\n-rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one\n\nReplacing a file is one thing. In this case we're deleting a directory\nand unknown number of files inside (in this case 'two' and 'three').\nIs this really a good thing to do?\n\nIf it's not but too late to do anything about git-checkout, could\ngit-restore do something better (and exactly what)?\n-- \nDuy\n"},{"id":"375500","messageId":"xmqq8sv99vac.fsf@gitster-ct.c.googlers.com","threadId":"51091","inReplyTo":"CACsJy8Bew3i6AL_XWfhLhCvdSFYVCGoEQepi9KLmSDPVmDu5Zg@mail.gmail.com","subject":"Re: Is git-checkout's restoring d/f conflict really sane?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-14T10:37:15Z","receivedAt":"2019-05-14T10:37:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> $ echo data > one\n> $ git add one\n> $ rm one\n> $ mkdir one\n> $ echo two > one/two\n> $ echo three > one/three\n> $ git checkout one\n> $ ls -l one\n> -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one\n>\n> Replacing a file is one thing. In this case we're deleting a directory\n> and unknown number of files inside (in this case 'two' and 'three').\n> Is this really a good thing to do?\n>\n> If it's not but too late to do anything about git-checkout, could\n> git-restore do something better (and exactly what)?\n\nThe user said \"I do not want whatever I have under name 'one' in the\nworking tree, and I want what I have as 'one' in the index instead\",\nso I tend to think that failing the request would be a disservice.\n\nI suspect that this will become even more right thing to do, in the\nnew world where the no-overlay mode becomes the default. Unlike\n\"checkout HEAD .\" that only adds to the set of paths in the working\ntree, \"restore HEAD .\" will remove what's in the working tree and in\nthe index but not in the HEAD, no?\n\n"},{"id":"375501","messageId":"CACsJy8DoxHoi0H3R91ovqDPjk0tN3Rr8fQOjaLt_2P9O3n9b_g@mail.gmail.com","threadId":"51091","inReplyTo":"xmqq8sv99vac.fsf@gitster-ct.c.googlers.com","subject":"Re: Is git-checkout's restoring d/f conflict really sane?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-05-14T10:49:03Z","receivedAt":"2019-05-14T10:49:32Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, May 14, 2019 at 5:37 PM Junio C Hamano wrote:\n>\n> Duy Nguyen writes:\n>\n> > $ echo data > one\n> > $ git add one\n> > $ rm one\n> > $ mkdir one\n> > $ echo two > one/two\n> > $ echo three > one/three\n> > $ git checkout one\n> > $ ls -l one\n> > -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one\n> >\n> > Replacing a file is one thing. In this case we're deleting a directory\n> > and unknown number of files inside (in this case 'two' and 'three').\n> > Is this really a good thing to do?\n> >\n> > If it's not but too late to do anything about git-checkout, could\n> > git-restore do something better (and exactly what)?\n>\n> The user said \"I do not want whatever I have under name 'one' in the\n> working tree, and I want what I have as 'one' in the index instead\",\n> so I tend to think that failing the request would be a disservice.\n\nExcept that sometimes the user has those \"oops that's not what I\nmeant\" moments (and I think it's more often \"I want to restore _file_\n'one'\"). One tricky thing in this situation is (to me) one/two and\none/three are untracked and we generally do not touch them unless\nrequested.\n\nTechnically 'one' is still tracked (even if it's a directory) so what\nwe're doing is right. I'm just not sure if there's some big surprise\nfactor here. And whether it's better to pause and double check with\nthe user before deleting everything.\n\n> I suspect that this will become even more right thing to do, in the\n> new world where the no-overlay mode becomes the default. Unlike\n> \"checkout HEAD .\" that only adds to the set of paths in the working\n> tree, \"restore HEAD .\" will remove what's in the working tree and in\n> the index but not in the HEAD, no?\n\nYes. It makes me really want 'git restore --diff [--stat]' just to\nshow what's going to be restored. A careful user may see something\nunexpected and examine more before really doing 'git restore'.\n-- \nDuy\n"},{"id":"375589","messageId":"xmqq1s108opt.fsf@gitster-ct.c.googlers.com","threadId":"51091","inReplyTo":"CACsJy8DoxHoi0H3R91ovqDPjk0tN3Rr8fQOjaLt_2P9O3n9b_g@mail.gmail.com","subject":"Re: Is git-checkout's restoring d/f conflict really sane?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-15T01:56:46Z","receivedAt":"2019-05-15T01:56:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Technically 'one' is still tracked (even if it's a directory) so what\n> we're doing is right. I'm just not sure if there's some big surprise\n> factor here. And whether it's better to pause and double check with\n> the user before deleting everything.\n\nI agree to all of the above, including the part \"technically it is\ncorrect\", but more importantly \"stop and double check\". \n\nAs changing between a directory and a non-directory is a rare event\nanyway, I do not mind making it a bit more cumbersome and say \"you\nasked me to check out a regular file 'one', but you have a directory\n'one', that has an unignored untracked file in it, so I'd refuse to\ndo so. Come back after you removed them manually, or use the '--force'\noption\".\n\nWe should not refuse if 'one' is an empty directory or all files in\nit are ignored, though.\n\nThanks.\n\n\n"}]}