{"thread":{"id":"50699","subject":"git MUST notify user when files will be deleted or overwritten by command","startedAt":"2019-03-09T10:19:13Z","lastAt":"2019-03-09T23:54:33Z","messageCount":5,"participants":["Dimitri Joukoff","Kevin Daudt","Duy Nguyen","Randall S. Becker","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"371019","messageId":"SYXPR01MB09577F5C4555C9068B606E11DD4E0@SYXPR01MB0957.ausprd01.prod.outlook.com","threadId":"50699","inReplyTo":null,"subject":"git MUST notify user when files will be deleted or overwritten by command","fromName":"Dimitri Joukoff","fromEmail":"dimitri.joukoff@griffithuni.edu.au","sentAt":"2019-03-09T10:19:03Z","receivedAt":"2019-03-09T10:19:13Z","isPatch":false,"sender":{"key":"dimitri.joukoff@griffithuni.edu.au","avatar":null},"body":"Hi,\n\nAs a relatively novice user of git, there have been far too many times\nthat I have lost data, sometimes quite a lot.  So this proposal is about\ncatering for the less experienced users and averting fits of anger and\nfrustration.  The only reason my computer still works is because my\nsub-conscious mind stops me from smashing it or throwing it against a\nwall.  It seems my sub-conscious mind has a pragmatic view of the world\nand understands that whilst I may receive instantaneous satisfaction at\nthe time, in the long term, the pain will be far worse, and thus\nprevents me from doing something rash.\n\n\nBelow is the detail of my proposal:\n\nWhenever a command is issued in git that will cause git to overwrite or\ndelete *ANY* files whose current state isn't already recorded in the\nrepository, git should prompt the user to confirm the operation. This\nincludes untracked files as well as files that are in the 'not staged'\nand 'staged' lists.\n\nTo make the consequences of the command transparent, the confirmation\nshould include a list of files that will be affected (perhaps in a\nsimilar way to how git status works).  The scope of the files listed\nmust match the scope of the command to be executed.  No hidden changes,\nno side-effects.\n\nSaying no to the confirmation should abort the command.\n\nIt may be useful to allow confirmation of individual files, but as a\nnovice user, I can't argue this point objectively, nor reason about its\nimplications and complexity.\n\nThis feature should be enabled by default whenever a clone or init\noperation are performed.\n\nThe user should be able to progressively reduce the range of commands\nand amount of confirmation interactions that take place.  The\nconfiguration technique could follow the already established procedure\nfor other configurable data in git.  So this could be done globally for\nthe user, or locally within each repository.\n\n\nAs a novice user, there may be further useful extensions of this idea,\nabout which I'm unable to reason.  So I welcome further elaboration of\nthe idea discussed above.\n\n\nBest regards,\nDimitri.\n\n\n\n\n\n"},{"id":"371021","messageId":"20190309104812.GA3403@alpha","threadId":"50699","inReplyTo":"SYXPR01MB09577F5C4555C9068B606E11DD4E0@SYXPR01MB0957.ausprd01.prod.outlook.com","subject":"Re: git MUST notify user when files will be deleted or overwritten by command","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2019-03-09T10:48:12Z","receivedAt":"2019-03-09T10:50:09Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Sat, Mar 09, 2019 at 10:19:03AM +0000, Dimitri Joukoff wrote:\n> Hi,\n> \n> As a relatively novice user of git, there have been far too many times\n> that I have lost data, sometimes quite a lot.  So this proposal is about\n> catering for the less experienced users and averting fits of anger and\n> frustration.  The only reason my computer still works is because my\n> sub-conscious mind stops me from smashing it or throwing it against a\n> wall.  It seems my sub-conscious mind has a pragmatic view of the world\n> and understands that whilst I may receive instantaneous satisfaction at\n> the time, in the long term, the pain will be far worse, and thus\n> prevents me from doing something rash.\n> \n\nYes, it can be very frustrating to lose things you did not intend to\nlose, so making sure your tooling limits the chances of that happing is\ncertainly a worthwile goal.\n\n> \n> Below is the detail of my proposal: > \n> Whenever a command is issued in git that will cause git to overwrite or\n> delete *ANY* files whose current state isn't already recorded in the\n> repository, git should prompt the user to confirm the operation. This\n> includes untracked files as well as files that are in the 'not staged'\n> and 'staged' lists.\n> \n> To make the consequences of the command transparent, the confirmation\n> should include a list of files that will be affected (perhaps in a\n> similar way to how git status works).  The scope of the files listed\n> must match the scope of the command to be executed.  No hidden changes,\n> no side-effects.\n> \n> Saying no to the confirmation should abort the command.\n> \n> It may be useful to allow confirmation of individual files, but as a\n> novice user, I can't argue this point objectively, nor reason about its\n> implications and complexity.\n> \n> This feature should be enabled by default whenever a clone or init\n> operation are performed.\n> \n> The user should be able to progressively reduce the range of commands\n> and amount of confirmation interactions that take place.  The\n> configuration technique could follow the already established procedure\n> for other configurable data in git.  So this could be done globally for\n> the user, or locally within each repository.\n> \n> \n> As a novice user, there may be further useful extensions of this idea,\n> about which I'm unable to reason.  So I welcome further elaboration of\n> the idea discussed above.\n> \n> \n> Best regards,\n> Dimitri.\n> \n\nA lot of confirmations only result in people automatically dismissing\nthem (confirmation saturation), missing the goal of what you intend.\n\nInstead of asking for confirmation, it's much better to allow people to\nundo these mistakes. You see the same pattern in gmail for example,\nwhere they hardly ask you for any confirmation, but instead show an undo\nbutton that allows you to undo the last operation. In my opinion this is\na better way to go then to add confirmations everywhere.\n\nI know this has come up on the git mailing list more often, but I cannot\nfind a relevant thread at this moment.\n\nKevin\n"},{"id":"371025","messageId":"CACsJy8CH7Q532cq2KAqKaJJBUz6B9N-f6OteOAusURSrYeoRow@mail.gmail.com","threadId":"50699","inReplyTo":"20190309104812.GA3403@alpha","subject":"Re: git MUST notify user when files will be deleted or overwritten by command","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-09T12:19:00Z","receivedAt":"2019-03-09T12:19:29Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Mar 9, 2019 at 5:50 PM Kevin Daudt <me@ikke.info> wrote:\n> I know this has come up on the git mailing list more often, but I cannot\n> find a relevant thread at this moment.\n\nThe last discussion is probably this one\n\nhttps://public-inbox.org/git/87wolzo7a1.fsf@evledraar.gmail.com/\n-- \nDuy\n"},{"id":"371051","messageId":"000401d4d6c8$f68bb020$e3a31060$@nexbridge.com","threadId":"50699","inReplyTo":"20190309104812.GA3403@alpha","subject":"RE: git MUST notify user when files will be deleted or overwritten by command","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-03-09T22:39:25Z","receivedAt":"2019-03-09T22:39:52Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 9, 2019 5:48, Kevin Daudt wrote:\n> On Sat, Mar 09, 2019 at 10:19:03AM +0000, Dimitri Joukoff wrote:\n> > Hi,\n> >\n> > As a relatively novice user of git, there have been far too many times\n> > that I have lost data, sometimes quite a lot.  So this proposal is\n> > about catering for the less experienced users and averting fits of\n> > anger and frustration.  The only reason my computer still works is\n> > because my sub-conscious mind stops me from smashing it or throwing it\n> > against a wall.  It seems my sub-conscious mind has a pragmatic view\n> > of the world and understands that whilst I may receive instantaneous\n> > satisfaction at the time, in the long term, the pain will be far\n> > worse, and thus prevents me from doing something rash.\n> >\n> \n> Yes, it can be very frustrating to lose things you did not intend to lose,\nso\n> making sure your tooling limits the chances of that happing is certainly a\n> worthwile goal.\n> \n> >\n> > Below is the detail of my proposal: > Whenever a command is issued in\n> > git that will cause git to overwrite or delete *ANY* files whose\n> > current state isn't already recorded in the repository, git should\n> > prompt the user to confirm the operation. This includes untracked\n> > files as well as files that are in the 'not staged'\n> > and 'staged' lists.\n> >\n> > To make the consequences of the command transparent, the confirmation\n> > should include a list of files that will be affected (perhaps in a\n> > similar way to how git status works).  The scope of the files listed\n> > must match the scope of the command to be executed.  No hidden\n> > changes, no side-effects.\n> >\n> > Saying no to the confirmation should abort the command.\n> >\n> > It may be useful to allow confirmation of individual files, but as a\n> > novice user, I can't argue this point objectively, nor reason about\n> > its implications and complexity.\n> >\n> > This feature should be enabled by default whenever a clone or init\n> > operation are performed.\n> >\n> > The user should be able to progressively reduce the range of commands\n> > and amount of confirmation interactions that take place.  The\n> > configuration technique could follow the already established procedure\n> > for other configurable data in git.  So this could be done globally\n> > for the user, or locally within each repository.\n> >\n> >\n> > As a novice user, there may be further useful extensions of this idea,\n> > about which I'm unable to reason.  So I welcome further elaboration of\n> > the idea discussed above.\n> \n> A lot of confirmations only result in people automatically dismissing them\n> (confirmation saturation), missing the goal of what you intend.\n> \n> Instead of asking for confirmation, it's much better to allow people to\nundo\n> these mistakes. You see the same pattern in gmail for example, where they\n> hardly ask you for any confirmation, but instead show an undo button that\n> allows you to undo the last operation. In my opinion this is a better way\nto\n> go then to add confirmations everywhere.\n> \n> I know this has come up on the git mailing list more often, but I cannot\nfind a\n> relevant thread at this moment.\n\nFirst, I really do not like the idea of confirmations. This could complicate\nscripting and would drive much of the work I do with git in Jenkins up a\nwall. You would need access to stdin for almost anything.\n\nSecond, I think an automatic undo has merit and could further differentiate\ngit from other DVCS and VCS systems. My thought is along the lines of\nstarting with the stash concept for each undo - almost like an auto-stash.\nBasically, any time you perform a working-directory modifying operation, a\nstash-like commit is added to the repository at HEAD (possibly ignoring\n.gitignore or precious files, like --include-untracked but in a config like\nundo.untracked=on, to avoid needing to remember to do this). I envision it\nbeing a stash without modifying the working-directory or changing the\nrepository state other than the \"undo\" unlike what stash does.\n\nConsidering the performance hit this *will* cause, I would want an option to\nnot do this (say, undo.enable=on/off, off by default unless there was some\nnewbie metric <j/k>, or maybe undo.fearful=high <j/k>), and a limit to the\nnumber of undoes (undo.limit=n), and an auto-drop capability so that when\nyou finally commit, you have the option to drop the undoes of the previous\nparent commit (undo.autoclean=on/off), or limit it to cleaning after more\nthan one commit is done beyond the commit where the undo exists\n(undo.autoclean=n). \n\nDeriving an \"undo\" off of a specific parent commit (HEAD), instead of\nderiving \"undoes\" on each other, might be helpful in resolving the question\nof how to you roll off (get rid of) undoes over time - making it just based\non the time of the snapshot and how many you want to keep. The reason I\nwould hang it off of a HEAD commit is that a checkout/switch would preserve\nthe undo stack so that when you returned to a branch, its undo stack would\nbe available, like stash.\n\nI would also see an impact on gc, potentially, to clean up old undoes beyond\na specific date.\n\nThis might need to start as a modification to stash, like --keep-index, but\nmore like taking picture, for example, --snapshot-only. Once you had that,\nbuilding an undo stack should be straight-forward, and undoing would be\nvirtually the same as a stash apply (might even *be* stash apply if the\n\"undo\" and stash were somehow the same thing conceptually). We're probably\nalso talking about a new command and subcommands, very similar to the stash\nstructure but querying either from HEAD or a specified commitish. If I only\nhad the time... ;)\n\nJust my musings.\n\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"371052","messageId":"dddaf761-29f0-36ce-c0c1-04e59d6c7bc9@iee.org","threadId":"50699","inReplyTo":"000401d4d6c8$f68bb020$e3a31060$@nexbridge.com","subject":"Re: git MUST notify user when files will be deleted or overwritten by command","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-03-09T23:54:27Z","receivedAt":"2019-03-09T23:54:33Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 09/03/2019 22:39, Randall S. Becker wrote:\n> On March 9, 2019 5:48, Kevin Daudt wrote:\n>> On Sat, Mar 09, 2019 at 10:19:03AM +0000, Dimitri Joukoff wrote:\n>>> Hi,\n>>>\n>>> As a relatively novice user of git, there have been far too many times\n>>> that I have lost data, sometimes quite a lot.  So this proposal is\n>>> about catering for the less experienced users and averting fits of\n>>> anger and frustration.  The only reason my computer still works is\n>>> because my sub-conscious mind stops me from smashing it or throwing it\n>>> against a wall.  It seems my sub-conscious mind has a pragmatic view\n>>> of the world and understands that whilst I may receive instantaneous\n>>> satisfaction at the time, in the long term, the pain will be far\n>>> worse, and thus prevents me from doing something rash.\n>>>\n>> Yes, it can be very frustrating to lose things you did not intend to lose,\n> so\n>> making sure your tooling limits the chances of that happing is certainly a\n>> worthwile goal.\n>>\n>>> Below is the detail of my proposal: > Whenever a command is issued in\n>>> git that will cause git to overwrite or delete *ANY* files whose\n>>> current state isn't already recorded in the repository, git should\n>>> prompt the user to confirm the operation. This includes untracked\n>>> files as well as files that are in the 'not staged'\n>>> and 'staged' lists.\n>>>\n>>> To make the consequences of the command transparent, the confirmation\n>>> should include a list of files that will be affected (perhaps in a\n>>> similar way to how git status works).  The scope of the files listed\n>>> must match the scope of the command to be executed.  No hidden\n>>> changes, no side-effects.\n>>>\n>>> Saying no to the confirmation should abort the command.\n>>>\n>>> It may be useful to allow confirmation of individual files, but as a\n>>> novice user, I can't argue this point objectively, nor reason about\n>>> its implications and complexity.\n>>>\n>>> This feature should be enabled by default whenever a clone or init\n>>> operation are performed.\n>>>\n>>> The user should be able to progressively reduce the range of commands\n>>> and amount of confirmation interactions that take place.  The\n>>> configuration technique could follow the already established procedure\n>>> for other configurable data in git.  So this could be done globally\n>>> for the user, or locally within each repository.\n>>>\n>>>\n>>> As a novice user, there may be further useful extensions of this idea,\n>>> about which I'm unable to reason.  So I welcome further elaboration of\n>>> the idea discussed above.\n>> A lot of confirmations only result in people automatically dismissing them\n>> (confirmation saturation), missing the goal of what you intend.\n>>\n>> Instead of asking for confirmation, it's much better to allow people to\n> undo\n>> these mistakes. You see the same pattern in gmail for example, where they\n>> hardly ask you for any confirmation, but instead show an undo button that\n>> allows you to undo the last operation. In my opinion this is a better way\n> to\n>> go then to add confirmations everywhere.\n>>\n>> I know this has come up on the git mailing list more often, but I cannot\n> find a\n>> relevant thread at this moment.\n> First, I really do not like the idea of confirmations. This could complicate\n> scripting and would drive much of the work I do with git in Jenkins up a\n> wall. You would need access to stdin for almost anything.\n>\n> Second, I think an automatic undo has merit and could further differentiate\n> git from other DVCS and VCS systems. My thought is along the lines of\n> starting with the stash concept for each undo - almost like an auto-stash.\n> Basically, any time you perform a working-directory modifying operation, a\n> stash-like commit is added to the repository at HEAD (possibly ignoring\n> .gitignore or precious files, like --include-untracked but in a config like\n> undo.untracked=on, to avoid needing to remember to do this). I envision it\n> being a stash without modifying the working-directory or changing the\n> repository state other than the \"undo\" unlike what stash does.\n>\n> Considering the performance hit this *will* cause, I would want an option to\n> not do this (say, undo.enable=on/off, off by default unless there was some\n> newbie metric <j/k>, or maybe undo.fearful=high <j/k>), and a limit to the\n> number of undoes (undo.limit=n), and an auto-drop capability so that when\n> you finally commit, you have the option to drop the undoes of the previous\n> parent commit (undo.autoclean=on/off), or limit it to cleaning after more\n> than one commit is done beyond the commit where the undo exists\n> (undo.autoclean=n).\n>\n> Deriving an \"undo\" off of a specific parent commit (HEAD), instead of\n> deriving \"undoes\" on each other, might be helpful in resolving the question\n> of how to you roll off (get rid of) undoes over time - making it just based\n> on the time of the snapshot and how many you want to keep. The reason I\n> would hang it off of a HEAD commit is that a checkout/switch would preserve\n> the undo stack so that when you returned to a branch, its undo stack would\n> be available, like stash.\n>\n> I would also see an impact on gc, potentially, to clean up old undoes beyond\n> a specific date.\n>\n> This might need to start as a modification to stash, like --keep-index, but\n> more like taking picture, for example, --snapshot-only. Once you had that,\n> building an undo stack should be straight-forward, and undoing would be\n> virtually the same as a stash apply (might even *be* stash apply if the\n> \"undo\" and stash were somehow the same thing conceptually). We're probably\n> also talking about a new command and subcommands, very similar to the stash\n> structure but querying either from HEAD or a specified commitish. If I only\n> had the time... ;)\n>\n> Just my musings.\n>\n> Randall\n\nThe key word to look for on the discussion list is 'precious'.\n\nHave a look at the various discussions \nhttps://public-inbox.org/git/?q=precious\n\nThere are quite a number of files that are otherwise trashable that one \nwould not want endless confirmations for - it is a tricky task.\n\n--\n\nPhilip\n\n"}]}