{"thread":{"id":"46285","subject":"Warning suggestion for git stash drop","startedAt":"2017-06-29T09:23:10Z","lastAt":"2017-07-18T07:16:57Z","messageCount":6,"participants":["Laurent Humblet","Junio C Hamano","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"323474","messageId":"CAFirYm_LLCUNdppZ7kKGwijJNNvhCaQtoJzRBVRsvhF+=bqgrw@mail.gmail.com","threadId":"46285","inReplyTo":null,"subject":"Warning suggestion for git stash drop","fromName":"Laurent Humblet","fromEmail":"laurent.humblet@gmail.com","sentAt":"2017-06-29T09:23:03Z","receivedAt":"2017-06-29T09:23:10Z","isPatch":false,"sender":{"key":"laurent.humblet@gmail.com","avatar":null},"body":"Hi all,\n\nWould it be possible to add an optional Yes/No when doing a 'git stash\ndrop'? Something similar as what happens when pushing on a remotely\nchecked out branch (with a config setting to turn the warning on/off).\n\nI know that you can always get your dropped stash back using git\nreflog but a small warning might be a useful feature to avoid unwanted\nstash drops on a regular basis.\n\nThank you for your work on this amazing little software,\nAll the best,\nLaurent\n"},{"id":"323491","messageId":"xmqqefu2tyzc.fsf@gitster.mtv.corp.google.com","threadId":"46285","inReplyTo":"CAFirYm_LLCUNdppZ7kKGwijJNNvhCaQtoJzRBVRsvhF+=bqgrw@mail.gmail.com","subject":"Re: Warning suggestion for git stash drop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-29T18:44:55Z","receivedAt":"2017-06-29T18:45:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Laurent Humblet writes:\n\n> Would it be possible to add an optional Yes/No when doing a 'git stash\n> drop'? Something similar as what happens when pushing on a remotely\n> checked out branch (with a config setting to turn the warning on/off).\n>\n> I know that you can always get your dropped stash back using git\n> reflog but a small warning might be a useful feature to avoid unwanted\n> stash drops on a regular basis.\n\nI sympathize with this, but the same principle also would apply many\ndestructive commands like \"git reset --hard\", \"git rm \", etc.\nand also \"/bin/rm -f\" ;-)\n\nI however do not think a good general way to do this without\nbreaking people's scripts. When they do 'stash drop' in their\nscripts, they know they want to get rid of the dropped stash\nentries, and they expect that the user may not necessarily be\nsitting in front of the shell to give the command a Yes (they\nprobably wouldn't even give the user a message \"the next step\nmay ask you to say Yes; please do so\").\n\nOn the other hand, just like \"git reset --hard\" and \"git clean -f\"\ndoes not have such safety (i.e. the user is aware that the command\nis destructive by giving \"--hard\" and \"-f\"), \"drop\" may be a sign\nthat the user knowingly doing something destructive.\n\nSo I dunno. \n\n\n\n\n"},{"id":"323494","messageId":"CAGZ79kYd+3OoUBcsTS9=S9qEUwKj9ypyHyjXLBW=KjWOVoae4A@mail.gmail.com","threadId":"46285","inReplyTo":"xmqqefu2tyzc.fsf@gitster.mtv.corp.google.com","subject":"Re: Warning suggestion for git stash drop","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-29T18:56:15Z","receivedAt":"2017-06-29T18:56:21Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano wrote:\n> Laurent Humblet writes:\n>\n>> Would it be possible to add an optional Yes/No when doing a 'git stash\n>> drop'? Something similar as what happens when pushing on a remotely\n>> checked out branch (with a config setting to turn the warning on/off).\n>>\n>> I know that you can always get your dropped stash back using git\n>> reflog but a small warning might be a useful feature to avoid unwanted\n>> stash drops on a regular basis.\n>\n> I sympathize with this, but the same principle also would apply many\n> destructive commands like \"git reset --hard\", \"git rm \", etc.\n> and also \"/bin/rm -f\" ;-)\n>\n> I however do not think a good general way to do this without\n> breaking people's scripts. When they do 'stash drop' in their\n> scripts, they know they want to get rid of the dropped stash\n> entries, and they expect that the user may not necessarily be\n> sitting in front of the shell to give the command a Yes (they\n> probably wouldn't even give the user a message \"the next step\n> may ask you to say Yes; please do so\").\n>\n> On the other hand, just like \"git reset --hard\" and \"git clean -f\"\n> does not have such safety (i.e. the user is aware that the command\n> is destructive by giving \"--hard\" and \"-f\"), \"drop\" may be a sign\n> that the user knowingly doing something destructive.\n>\n> So I dunno.\n>\n\nI was about to propose to have an easy undo operation, such as the\nreflog. But then I checked the man page for git-stash and it already says:\n\n older stashes are found in the reflog of this reference and can be named\n using the usual reflog syntax (e.g. stash@{0} is the most recently\n created stash, stash@{1} is the one before it, stash@{2.hours.ago} is\n also possible). Stashes may also be referenced by specifying\njust the stash\n index (e.g. the integer n is equivalent to stash@{n})\n\nMaybe that needs to be polished a bit more?\n\nI myself used the stash back then (I don't use it any more), and I assumed\nthe stash was a stack of changes, but the data structure seems to imply it\nis only one thing that can be stashed and the reflog enables the stacking\npart, such that a dropped stash is gone and is not recorded in the reflog.\nDropping a stash seems to just erase the topmost line from the stash reflog,\nso it really is as destructive an \"/bin/rm -f\"\n\nSo getting back a dropped stash via the reflog is not via asking for a stash\nreflog but rather for HEADs or a branchs reflog, which may be complicated.\n"},{"id":"323589","messageId":"CAFirYm_UzUe=zSefAVpt45OuEwKyn7bAZbumLXYWbPFVRahPew@mail.gmail.com","threadId":"46285","inReplyTo":"CAGZ79kYd+3OoUBcsTS9=S9qEUwKj9ypyHyjXLBW=KjWOVoae4A@mail.gmail.com","subject":"Re: Warning suggestion for git stash drop","fromName":"Laurent Humblet","fromEmail":"laurent.humblet@gmail.com","sentAt":"2017-06-30T18:33:49Z","receivedAt":"2017-06-30T18:33:55Z","isPatch":false,"sender":{"key":"laurent.humblet@gmail.com","avatar":null},"body":"Thank you for your feedback.\n\nI suppose that turning a hypothetical confirmation option 'on' would\nimpact a stash pop for instance as it automatically drops the stash if\nit was applied without conflicts.\n\nWhat about a --confirm flag? You could then simply alias 'git stash\ndrop --confirm' locally and it wouldn't impact anything else?\n\nHave a great week-end!\n\nOn 29 June 2017 at 20:56, Stefan Beller wrote:\n> On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano wrote:\n>> Laurent Humblet writes:\n>>\n>>> Would it be possible to add an optional Yes/No when doing a 'git stash\n>>> drop'? Something similar as what happens when pushing on a remotely\n>>> checked out branch (with a config setting to turn the warning on/off).\n>>>\n>>> I know that you can always get your dropped stash back using git\n>>> reflog but a small warning might be a useful feature to avoid unwanted\n>>> stash drops on a regular basis.\n>>\n>> I sympathize with this, but the same principle also would apply many\n>> destructive commands like \"git reset --hard\", \"git rm \", etc.\n>> and also \"/bin/rm -f\" ;-)\n>>\n>> I however do not think a good general way to do this without\n>> breaking people's scripts. When they do 'stash drop' in their\n>> scripts, they know they want to get rid of the dropped stash\n>> entries, and they expect that the user may not necessarily be\n>> sitting in front of the shell to give the command a Yes (they\n>> probably wouldn't even give the user a message \"the next step\n>> may ask you to say Yes; please do so\").\n>>\n>> On the other hand, just like \"git reset --hard\" and \"git clean -f\"\n>> does not have such safety (i.e. the user is aware that the command\n>> is destructive by giving \"--hard\" and \"-f\"), \"drop\" may be a sign\n>> that the user knowingly doing something destructive.\n>>\n>> So I dunno.\n>>\n>\n> I was about to propose to have an easy undo operation, such as the\n> reflog. But then I checked the man page for git-stash and it already says:\n>\n> older stashes are found in the reflog of this reference and can be named\n> using the usual reflog syntax (e.g. stash@{0} is the most recently\n> created stash, stash@{1} is the one before it, stash@{2.hours.ago} is\n> also possible). Stashes may also be referenced by specifying\n> just the stash\n> index (e.g. the integer n is equivalent to stash@{n})\n>\n> Maybe that needs to be polished a bit more?\n>\n> I myself used the stash back then (I don't use it any more), and I assumed\n> the stash was a stack of changes, but the data structure seems to imply it\n> is only one thing that can be stashed and the reflog enables the stacking\n> part, such that a dropped stash is gone and is not recorded in the reflog.\n> Dropping a stash seems to just erase the topmost line from the stash reflog,\n> so it really is as destructive an \"/bin/rm -f\"\n>\n> So getting back a dropped stash via the reflog is not via asking for a stash\n> reflog but rather for HEADs or a branchs reflog, which may be complicated.\n"},{"id":"323598","messageId":"xmqqinjdqo1i.fsf@gitster.mtv.corp.google.com","threadId":"46285","inReplyTo":"CAFirYm_UzUe=zSefAVpt45OuEwKyn7bAZbumLXYWbPFVRahPew@mail.gmail.com","subject":"Re: Warning suggestion for git stash drop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-06-30T19:21:45Z","receivedAt":"2017-06-30T19:21:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Laurent Humblet writes:\n\n> Thank you for your feedback.\n>\n> I suppose that turning a hypothetical confirmation option 'on' would\n> impact a stash pop for instance as it automatically drops the stash if\n> it was applied without conflicts.\n>\n> What about a --confirm flag? You could then simply alias 'git stash\n> drop --confirm' locally and it wouldn't impact anything else?\n\nI think that is probably trivial to add, but how would you make sure\nyou give it? One way may be to train your fingers to type \"git sd\"\nwith something like this in your ~/.gitconfig:\n\n\t[alias] sd = \"stash drop --confirm\"\n\nbut at that point, you could instead have something like the\nfollowing in you ~/bin/git-sd and get the same effect:\n\n\t#!/bin/sh\n\tif tty -s\n\tthen\n\t\techo >&2 \"are you sure you want to drop all stash entries?\"\n\t\tcase \"$(read)\" in\n\t\t[Yy]*) ;;\n\t\t*) echo >&2 \"ok, let's not drop 'em\"; exit 0 ;;\n esac\n\tfi\n\texec git stash drop\n\nwithout adding the \"--confirm\" option at all.\n\nSo I am not sure that would get us closer to a satisfactory solution\nto your original problem. \n\nRetroactively adding an end-user safety is hard.\n\n> Have a great week-end!\n\nYou too.\n"},{"id":"324698","messageId":"CAFirYm8G-8DAfapeSvuRk1QghBZE1W0Pa1h+NDMvVNT5Kd354w@mail.gmail.com","threadId":"46285","inReplyTo":"xmqqinjdqo1i.fsf@gitster.mtv.corp.google.com","subject":"Re: Warning suggestion for git stash drop","fromName":"Laurent Humblet","fromEmail":"laurent.humblet@gmail.com","sentAt":"2017-07-18T07:16:50Z","receivedAt":"2017-07-18T07:16:57Z","isPatch":false,"sender":{"key":"laurent.humblet@gmail.com","avatar":null},"body":"Oh great, an answer 20 days later ... Sorry about this.\n\nI have been reading a bit on the topic and found that for Bash we\nshould be using shell functions over aliases so I wrote this function\nto be simply added to the .bashrc:\n\n# 'git stash drop' confirm shell function\ngit() {\n if [[ $@ == \"stash drop\" ]]; then\n read -r -p \"Are you sure you want to drop your stash? [y/N] \" response\n case \"$response\" in\n [yY][eE][sS]|[yY])\n command git \"$@\"\n ;;\n esac\n else\n command git \"$@\"\n fi\n}\n\nBe careful, I'm no Bash expert and I don't believe it is fully POSIX\ncompliant but it's a good start I think. This could also be used for\nthe 'rm -rf' command or any other potentially dangerous command I\nbelieve. Maybe there is a place for a .bashrc_safe_shell_functions\nthat could be loaded by the user to add confirmation before all\npotentially dangerous commands but it'll be for another thread.\n\nThank you for your help guys and keep up with your excellent work on Git!\n\nAll the best,\nLaurent\n\n\nOn 30 June 2017 at 21:21, Junio C Hamano wrote:\n> Laurent Humblet writes:\n>\n>> Thank you for your feedback.\n>>\n>> I suppose that turning a hypothetical confirmation option 'on' would\n>> impact a stash pop for instance as it automatically drops the stash if\n>> it was applied without conflicts.\n>>\n>> What about a --confirm flag? You could then simply alias 'git stash\n>> drop --confirm' locally and it wouldn't impact anything else?\n>\n> I think that is probably trivial to add, but how would you make sure\n> you give it? One way may be to train your fingers to type \"git sd\"\n> with something like this in your ~/.gitconfig:\n>\n> [alias] sd = \"stash drop --confirm\"\n>\n> but at that point, you could instead have something like the\n> following in you ~/bin/git-sd and get the same effect:\n>\n> #!/bin/sh\n> if tty -s\n> then\n> echo >&2 \"are you sure you want to drop all stash entries?\"\n> case \"$(read)\" in\n> [Yy]*) ;;\n> *) echo >&2 \"ok, let's not drop 'em\"; exit 0 ;;\n> esac\n> fi\n> exec git stash drop\n>\n> without adding the \"--confirm\" option at all.\n>\n> So I am not sure that would get us closer to a satisfactory solution\n> to your original problem.\n>\n> Retroactively adding an end-user safety is hard.\n>\n>> Have a great week-end!\n>\n> You too.\n"}]}