{"thread":{"id":"15479","subject":"RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","startedAt":"2008-09-10T19:12:21Z","lastAt":"2008-09-12T15:41:26Z","messageCount":18,"participants":["Eric Raible","Changsheng Jiang","Elijah Newren","Mike Hommey","Junio C Hamano","Jeff Whiteside","Miklos Vajna"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90377","messageId":"279b37b20809101212g57e9ad99qbf6fa15888679894@mail.gmail.com","threadId":"15479","inReplyTo":null,"subject":"RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-10T19:12:21Z","receivedAt":"2008-09-10T19:12:21Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"In http://marc.theaimsgroup.com/?l=git&m=114917892328066\n(references by http://git.or.cz/gitwiki/GitFaq), Linus says:\n\n'And \"git reset\" won't be deleting files it doesn't track (it had _better_\nnot touch them), even more so when it has been told to ignore them, so it\nmakes total sense to _not_ delete them when doing that reset.'\n\nNow consider this example:\n\n# Create a single commit in a new repo (so that we have a HEAD)\nmkdir xx\ncd xx\ngit init\ngit commit --allow-empty -m\"initial\"\n# Add an important file\necho \"Important stuff\" > file42\ngit add file42\ngit status # -> new file: file42\nls # -> file42, or course\ngit reset --hard\nls # -> nothing\n\nI would argue that as a \"new file\" (as reported by git status)\nthat file42 was never actually tracked by git. Sure, it _would_\nhave been tracked in the future, but git never actually tracked it\n(it's not part of any commits).\n\nSo in this scenario wouldn't it make more sense for\n\"git reset --hard\" to handle file42 as \"git reset\" does\ninstead of deleting it w/out a trace [1]?\n\nThe same question goes for \"git checkout -f\", too, I suppose.\n\nI actually accidentally deleted hundred of newly added files yesterday\ndoing just this. https://mozy.com/?code=V3D4MM) saved my butt,\nbut it wasn't pleasant.\n\n- Eric\n\n[1] - There's not even a reflog entry. Sure, \"git fsck\" can be\nused, but that's hardly a friendly fallback.\n"},{"id":"90404","messageId":"eafc0afe0809101914lff5b23ehaf625d702fbd9b5d@mail.gmail.com","threadId":"15479","inReplyTo":"eafc0afe0809101912v72916d3hce9ae5d6812f0db8@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Changsheng Jiang","fromEmail":"jiangzuoyan@gmail.com","sentAt":"2008-09-11T02:14:38Z","receivedAt":"2008-09-11T02:14:38Z","isPatch":false,"sender":{"key":"jiangzuoyan@gmail.com","avatar":"https://gravatar.com/avatar/61eb7704963065c5937698bacbc1412b6083e1d43f2cc9642999fe10b2e582f8?d=mp&s=160"},"body":"I think the current behavior is better than you described. If you want\nto ignore some files, you can added it to the exclude file. All files\nnot excluded in the repo directory is maintained by git.\n"},{"id":"90405","messageId":"51419b2c0809101938v30e5a1aflf944027aedc2d900@mail.gmail.com","threadId":"15479","inReplyTo":"eafc0afe0809101914lff5b23ehaf625d702fbd9b5d@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-11T02:38:13Z","receivedAt":"2008-09-11T02:38:13Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Sep 10, 2008 at 8:14 PM, Changsheng Jiang wrote:\n> I think the current behavior is better than you described. If you want\n> to ignore some files, you can added it to the exclude file. All files\n> not excluded in the repo directory is maintained by git.\n\nNo, there's a limbo state -- the \"untracked\" files shown by git status\n(which is the default state; these are files that have not been\nexplicitly requested to be ignored or be tracked). Note the quote\nfrom Linus at the beginning of Eric's email that specifically\nreferences this.\n\nAnyway, Eric wasn't really talking about ignoring files, since he was\nexplicitly adding them for the next commit. It's just that at some\npoint he changed his mind and decided he didn't want to include any of\nthe changes he had already made in the next commit, but was surprised\nwhen git reset --hard deleted the files from both the index and\nworking copy instead of just the index. git reset --hard really is\nmeant for throwing away unwanted stuff (particularly including in the\nworking directory), but I can see how he may have expected behavior\nmore along the lines of git rm --cached for those particular files. I\ndon't agree with that viewpoint (I see files as tracked as soon as you\nstage it, not once you commit it), but I can see where the expectation\ncomes from.\n\nJust my thoughts,\nElijah\n"},{"id":"90407","messageId":"279b37b20809101946k309ad113neb7d051f1c6c410e@mail.gmail.com","threadId":"15479","inReplyTo":"eafc0afe0809101912v72916d3hce9ae5d6812f0db8@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T02:46:40Z","receivedAt":"2008-09-11T02:46:40Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Wed, Sep 10, 2008 at 7:12 PM, Changsheng Jiang wrote:\n> I think the current behavior is better than you described. If you want to\n> ignore some files, you can added it to the exclude file. All files not\n> excluded in the repo directory is maintained by git.\n\nThat doesn't really address the problem. This is an\nupdated example that specifically ignores the file:\n\n# Create a single commit in a new repo (so that we have a HEAD)\nmkdir xx\ncd xx\ngit init\ngit commit --allow-empty -m\"initial\"\n# Add an important file\necho \"Important stuff\" > file42\ngit add file42\necho file42 > .gitignore\ngit status # -> new file: file42\nls # -> file42, or course\ngit reset --hard\nls # -> nothing\n\nSo not only was file42 never actually tracked by git\n(IMHO - I realize that this is debatable) but it was also\nspecifically ignored, and it is _still_ deleted w/out a trace!\n\nI realize that \"git reset\" will simply unstage the new file\nin either case (w or w/out .gitignore), but the consequences\nof an accidental \"git reset --hard\" are pretty severe in this\ncase. This behavior seems definitely contrary to Linus's\nexplanation:\n\n And \"git reset\" won't be deleting files it doesn't track (it had _better_\n not touch them), even more so when it has been told to ignore them, so it\n makes total sense to _not_ delete them when doing that reset.\n\n- Eric\n"},{"id":"90413","messageId":"eafc0afe0809102305u6de85ef3ib2c08004dea8d6f9@mail.gmail.com","threadId":"15479","inReplyTo":"279b37b20809101946k309ad113neb7d051f1c6c410e@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Changsheng Jiang","fromEmail":"jiangzuoyan@gmail.com","sentAt":"2008-09-11T06:05:49Z","receivedAt":"2008-09-11T06:05:49Z","isPatch":false,"sender":{"key":"jiangzuoyan@gmail.com","avatar":"https://gravatar.com/avatar/61eb7704963065c5937698bacbc1412b6083e1d43f2cc9642999fe10b2e582f8?d=mp&s=160"},"body":"I don't know what version of you git, my git with version 1.5.4.5\ndoesn't delete the file file42 after git-reset.\n\nBTW, if you added the file42 to .gitignore, why git-status still\nreported \"new file\" file42\"?\n\nYours sincerely,\nChangsheng Jiang\npubkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x40C37374\n\n\n\nOn Thu, Sep 11, 2008 at 10:46, Eric Raible wrote:\n> On Wed, Sep 10, 2008 at 7:12 PM, Changsheng Jiang wrote:\n>> I think the current behavior is better than you described. If you want to\n>> ignore some files, you can added it to the exclude file. All files not\n>> excluded in the repo directory is maintained by git.\n>\n> That doesn't really address the problem. This is an\n> updated example that specifically ignores the file:\n>\n> # Create a single commit in a new repo (so that we have a HEAD)\n> mkdir xx\n> cd xx\n> git init\n> git commit --allow-empty -m\"initial\"\n> # Add an important file\n> echo \"Important stuff\" > file42\n> git add file42\n> echo file42 > .gitignore\n> git status # -> new file: file42\n> ls # -> file42, or course\n> git reset --hard\n> ls # -> nothing\n>\n> So not only was file42 never actually tracked by git\n> (IMHO - I realize that this is debatable) but it was also\n> specifically ignored, and it is _still_ deleted w/out a trace!\n>\n> I realize that \"git reset\" will simply unstage the new file\n> in either case (w or w/out .gitignore), but the consequences\n> of an accidental \"git reset --hard\" are pretty severe in this\n> case. This behavior seems definitely contrary to Linus's\n> explanation:\n>\n> And \"git reset\" won't be deleting files it doesn't track (it had _better_\n> not touch them), even more so when it has been told to ignore them, so it\n> makes total sense to _not_ delete them when doing that reset.\n>\n> - Eric\n>\n"},{"id":"90414","messageId":"20080911061454.GA8167@glandium.org","threadId":"15479","inReplyTo":"279b37b20809101212g57e9ad99qbf6fa15888679894@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-09-11T06:14:54Z","receivedAt":"2008-09-11T06:14:54Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Sep 10, 2008 at 12:12:21PM -0700, Eric Raible wrote:\n> In http://marc.theaimsgroup.com/?l=git&m=114917892328066\n> (references by http://git.or.cz/gitwiki/GitFaq), Linus says:\n> \n> 'And \"git reset\" won't be deleting files it doesn't track (it had _better_\n> not touch them), even more so when it has been told to ignore them, so it\n> makes total sense to _not_ delete them when doing that reset.'\n> \n> Now consider this example:\n> \n> # Create a single commit in a new repo (so that we have a HEAD)\n> mkdir xx\n> cd xx\n> git init\n> git commit --allow-empty -m\"initial\"\n> # Add an important file\n> echo \"Important stuff\" > file42\n> git add file42\n> git status # -> new file: file42\n> ls # -> file42, or course\n> git reset --hard\n> ls # -> nothing\n> \n> I would argue that as a \"new file\" (as reported by git status)\n> that file42 was never actually tracked by git. Sure, it _would_\n> have been tracked in the future, but git never actually tracked it\n> (it's not part of any commits).\n> \n> So in this scenario wouldn't it make more sense for\n> \"git reset --hard\" to handle file42 as \"git reset\" does\n> instead of deleting it w/out a trace [1]?\n> \n> The same question goes for \"git checkout -f\", too, I suppose.\n> \n> I actually accidentally deleted hundred of newly added files yesterday\n> doing just this. https://mozy.com/?code=V3D4MM) saved my butt,\n> but it wasn't pleasant.\n> \n> - Eric\n> \n> [1] - There's not even a reflog entry. Sure, \"git fsck\" can be\n> used, but that's hardly a friendly fallback.\n\nNote that reflog only contains references to commit sha1s, so it can't\ntrack index status. An index log could be interesting, though, but it\nwould need to expire much faster than reflog.\n\nMike\n"},{"id":"90415","messageId":"loom.20080911T061309-23@post.gmane.org","threadId":"15479","inReplyTo":"eafc0afe0809102305u6de85ef3ib2c08004dea8d6f9@mail.gmail.com","subject":"Re: RFC: perhaps a","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T06:15:34Z","receivedAt":"2008-09-11T06:15:34Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Changsheng Jiang gmail.com> writes:\n> \n> I don't know what version of you git, my git with version 1.5.4.5\n> doesn't delete the file file42 after git-reset.\n\nAll examples from me are version 1.6.0.1.436.g09e16c.dirty or later.\n"},{"id":"90450","messageId":"51419b2c0809110932r4e8c833fx740ccb0c8e46f0af@mail.gmail.com","threadId":"15479","inReplyTo":"eafc0afe0809102305u6de85ef3ib2c08004dea8d6f9@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-11T16:32:33Z","receivedAt":"2008-09-11T16:32:33Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Sep 11, 2008 at 12:05 AM, Changsheng Jiang\n wrote:\n> I don't know what version of you git, my git with version 1.5.4.5\n> doesn't delete the file file42 after git-reset.\n\nHe stated the same with his version. The point wasn't the behavior of\ngit reset, but of git reset --hard.\n\n> BTW, if you added the file42 to .gitignore, why git-status still\n> reported \"new file\" file42\"?\n\n>From the gitignore(5) manpage:\n\n\"Note that all the gitignore files really concern only files that are\nnot already tracked by git; in order to ignore uncommitted changes in\nalready tracked files, please refer to...\"\n\nOnce you run git add, the file is tracked (unless you do something to\nexplicitly stop tracking it).\n\n\nHope that helps,\nElijah\n"},{"id":"90473","messageId":"loom.20080911T202202-144@post.gmane.org","threadId":"15479","inReplyTo":"20080911061454.GA8167@glandium.org","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T20:26:30Z","receivedAt":"2008-09-11T20:26:30Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Mike Hommey glandium.org> writes:\n\n> Note that reflog only contains references to commit sha1s, so it can't\n> track index status.\n\nYes I realize that.\n\nMy point was that the file is entirely gone (except via \"git fsck\").\nI wouldn't expect the reflog to reference it, but I was just mentioning\nit for completeness (since it's often help in recovering from types of\nlossage).\n"},{"id":"90475","messageId":"loom.20080911T204256-821@post.gmane.org","threadId":"15479","inReplyTo":"51419b2c0809101938v30e5a1aflf944027aedc2d900@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T20:50:27Z","receivedAt":"2008-09-11T20:50:27Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Elijah Newren gmail.com> writes:\n\n> Anyway, Eric wasn't really talking about ignoring files, since he was\n> explicitly adding them for the next commit. It's just that at some\n> point he changed his mind and decided he didn't want to include any of\n> the changes he had already made in the next commit, but was surprised\n> when git reset --hard deleted the files from both the index and\n> working copy instead of just the index. git reset --hard really is\n> meant for throwing away unwanted stuff (particularly including in the\n> working directory), but I can see how he may have expected behavior\n> more along the lines of git rm --cached for those particular files. I\n> don't agree with that viewpoint (I see files as tracked as soon as you\n> stage it, not once you commit it), but I can see where the expectation\n> comes from.\n> \n> Just my thoughts,\n> Elijah\n\nYes, you have a 100% correct understand of what I'm trying to say.\nBut can you see a downside to \"git reset --hard\" treating newly\nadded files as \"git reset\"?\n\nWiping out existing files (with no realistic recovery) is a bit harsh,\nisn't it? Especially when AFAICS there's no downside to leaving the\nuntracked files as they were before they were \"git add\"-ed.\n\n- Eric\n"},{"id":"90479","messageId":"279b37b20809111424y73a3f6b9xe7f5019b9ba0da16@mail.gmail.com","threadId":"15479","inReplyTo":"3ab397d0809111022m24c81bd9y2520f6be478babd3@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T21:24:51Z","receivedAt":"2008-09-11T21:24:51Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Sep 11, 2008 at 10:22 AM, Jeff Whiteside\n wrote:\n> And if you want to delete all untracked files\n> ls | sed s/`git status --index --filenamesonly`//g | rm\n> ls | sed s/`git status --commitrepo --filenamesonly`//g | rm\n> (I realize those commands don't actually work, but I'm a noob.)\n\n\"git clean\" (http://www.kernel.org/pub/software/scm/git/docs/git-clean.html)\nwill delete untracked file.\n\n> So that 'tracked by git' isn't just another ambiguous semantic.\n\nWhile I can't find where it might be explicitly defined, it does seem\nclear that a file/dir is \"tracked\" as soon as it's added.\n\nMy question is why \"git reset --hard\" can't make a special case for\n_newly added_ tracked files. After all, \"git status\" knows that they're\n\"new files\", and \"git reset --hard\" could realize that wiping them off\nthe face of the earth isn't the most helpful thing possible.\n\n- Eric\n"},{"id":"90480","messageId":"7vd4jas6x8.fsf@gitster.siamese.dyndns.org","threadId":"15479","inReplyTo":"loom.20080911T204256-821@post.gmane.org","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-11T21:34:43Z","receivedAt":"2008-09-11T21:34:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Raible writes:\n\n> Yes, you have a 100% correct understand of what I'm trying to say.\n> But can you see a downside to \"git reset --hard\" treating newly\n> added files as \"git reset\"?\n\nOf course. The --hard option is called --hard without inviting short\noption for a reason.\n\nI am actually somewhat sympathetic to your point, but you would want\n\"reset --hard\" to remove that path when a path does not exist in the HEAD\nbut in index in other cases. And it is my experience (and I presume you\ncan guess I have longer git experience than any of you ;-) that far more\noften than not that is what is desirable.\n\nConsider:\n\n (1) Your branch does not have \"path\";\n\n (2) You once thought you want addition of the \"path\" made in another\n branch;\n\n (3) So you did:\n\n $ git checkout another -- path\n\n (4) After more hacking, it turns out that the avenue you chose to reach\n your goal, including the addition of the \"path\", was a mistake, and\n you regret having wasted some time. You want to go back to the\n current HEAD:\n\n $ git reset --hard\n\nThe state after (3) is \"HEAD does not have path, index and work tree has\nit\". In step (4) you would want \"git reset --hard\" to get rid of such a\npath.\n\nAnd it is no different from the case where you add the path manually to\nthe index. Both are \"you thought you wanted it, but you changed your\nmind\".\n\nAnother example is getting rid of crufts from a conflicted merge. It may\nbring in many new paths in your index and the working tree. You would\nwant a \"git reset --hard\" to get rid of all of them. Not removing the\npaths that are not in HEAD but in index and working tree is far worse in\nthis case because merging is often done from other people's tree that you\nmay not be familiar with (i.e. you wanted to study their tree after\nmerging), so it is harder for you to hand-clean after \"reset\" if a hard\nreset does not do it for you.\n"},{"id":"90487","messageId":"279b37b20809111519o76bea81br738983b4cda1978e@mail.gmail.com","threadId":"15479","inReplyTo":"7vd4jas6x8.fsf@gitster.siamese.dyndns.org","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T22:19:25Z","receivedAt":"2008-09-11T22:19:25Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Sep 11, 2008 at 2:34 PM, Junio C Hamano wrote:\n> Eric Raible writes:\n>\n>> But can you see a downside to \"git reset --hard\" treating newly\n>> added files as \"git reset\"?\n>\n> Of course. The --hard option is called --hard without inviting short\n> option for a reason.\n>\n> [various good reasons snipped]\n\nThanks for the definitive response. I suppose that I had been getting\nrather cavalier about --hard. Now my expectations are more aligned with\nreality.\n\nAnd that reality makes perfect sense, it's just a bit harsh when hundreds\nof important files get obliterated!\n\n- Eric\n"},{"id":"90494","messageId":"3ab397d0809111604r5d9dda04p32a987208d1fa92d@mail.gmail.com","threadId":"15479","inReplyTo":"279b37b20809111519o76bea81br738983b4cda1978e@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Jeff Whiteside","fromEmail":"jeff.m.whiteside@gmail.com","sentAt":"2008-09-11T23:04:19Z","receivedAt":"2008-09-11T23:04:19Z","isPatch":false,"sender":{"key":"jeff.m.whiteside@gmail.com","avatar":null},"body":"The command is wrapped up in all kinds of semantics at which you have\nto guess or read tons of vague or outdated literature. That's what\nmakes git's learning curve so retarded.\n\nWhy is it not just git reset --index or git reset\n--worktree or git reset --commitrepo REVISION or git reset\n--all ?\nAnd if you want to delete all untracked files\n ls | sed s/`git status --index --filenamesonly`//g | rm\n ls | sed s/`git status --commitrepo --filenamesonly`//g | rm\n (I realize those commands don't actually work, but I'm a noob.)\n\nSo that 'tracked by git' isn't just another ambiguous semantic.\nInstead 'Tracked by index'/'Tracked by commitrepo'.\n"},{"id":"90499","messageId":"279b37b20809111629s3c91ae4ci33135535812383e3@mail.gmail.com","threadId":"15479","inReplyTo":"3ab397d0809111604r5d9dda04p32a987208d1fa92d@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T23:29:40Z","receivedAt":"2008-09-11T23:29:40Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Sep 11, 2008 at 4:04 PM, Jeff Whiteside\n wrote:\n> And if you want to delete all untracked files\n> ls | sed s/`git status --index --filenamesonly`//g | rm\n> ls | sed s/`git status --commitrepo --filenamesonly`//g | rm\n> (I realize those commands don't actually work, but I'm a noob.)\n\n\"git clean\" will remove untracked files.\n"},{"id":"90501","messageId":"20080911233941.GP4829@genesis.frugalware.org","threadId":"15479","inReplyTo":"279b37b20809111424y73a3f6b9xe7f5019b9ba0da16@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-09-11T23:39:41Z","receivedAt":"2008-09-11T23:39:41Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Sep 11, 2008 at 02:24:51PM -0700, Eric Raible wrote:\n> My question is why \"git reset --hard\" can't make a special case for\n> _newly added_ tracked files. After all, \"git status\" knows that they're\n> \"new files\", and \"git reset --hard\" could realize that wiping them off\n> the face of the earth isn't the most helpful thing possible.\n\nI rarely need this, but I use 'git read-tree -m HEAD' before git reset\n--hard in case I want such a behaviour.\n"},{"id":"90503","messageId":"279b37b20809111649h77666a46u362dddfa1b40e0ca@mail.gmail.com","threadId":"15479","inReplyTo":"20080911233941.GP4829@genesis.frugalware.org","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-09-11T23:49:54Z","receivedAt":"2008-09-11T23:49:54Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Sep 11, 2008 at 4:39 PM, Miklos Vajna wrote:\n> On Thu, Sep 11, 2008 at 02:24:51PM -0700, Eric Raible wrote:\n>> My question is why \"git reset --hard\" can't make a special case for\n>> _newly added_ tracked files. After all, \"git status\" knows that they're\n>> \"new files\", and \"git reset --hard\" could realize that wiping them off\n>> the face of the earth isn't the most helpful thing possible.\n>\n> I rarely need this, but I use 'git read-tree -m HEAD' before git reset\n> --hard in case I want such a behaviour.\n\nWhat advantages does \"git read-tree -m HEAD\" have over \"git reset\" or\n\"git rm --cached \"?\n"},{"id":"90571","messageId":"20080912154126.GW4829@genesis.frugalware.org","threadId":"15479","inReplyTo":"279b37b20809111649h77666a46u362dddfa1b40e0ca@mail.gmail.com","subject":"Re: RFC: perhaps a \"new file\" should not be deleted by \"git reset --hard\"","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-09-12T15:41:26Z","receivedAt":"2008-09-12T15:41:26Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Sep 11, 2008 at 04:49:54PM -0700, Eric Raible wrote:\n> What advantages does \"git read-tree -m HEAD\" have over \"git reset\" or\n> \"git rm --cached \"?\n\nNothing. I should stop advertising that I still use a lot of plumbing\nwhen a porcelain like 'git reset' does the job as well. ;-(\n\nThanks for the correction.\n"}]}