{"thread":{"id":"38572","subject":"Experience with Recovering From User Error (And suggestions for improvements)","startedAt":"2015-02-16T10:41:49Z","lastAt":"2015-02-19T23:43:16Z","messageCount":11,"participants":["Armin Ronacher","Ævar Arnfjörð Bjarmason","Duy Nguyen","Michael J Gruber","Kyle J. McKay","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256144","messageId":"54E1C96D.2080109@active-4.com","threadId":"38572","inReplyTo":null,"subject":"Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Armin Ronacher","fromEmail":"armin.ronacher@active-4.com","sentAt":"2015-02-16T10:41:49Z","receivedAt":"2015-02-16T10:41:49Z","isPatch":false,"sender":{"key":"armin.ronacher@active-4.com","avatar":"https://gravatar.com/avatar/161ace72b12acb2f7e0db38599b74aca8f054dbdc3aae445d0d79cebb537950f?d=mp&s=160"},"body":"Hi,\n\nLong story short: I failed big time yesterday with accidentally \nexecuting git reset hard in the wrong terminal window but managed to \nrecover my changes from the staging area by manually examining blobs \ntouched recently.\n\nAfter that however I figured I might want to add a precaution for myself \nthat would have helped there.  git fsck is quite nice, but unfortunately \nit does not help if you do not have a commit.  So I figured it might be \nnice to create a dangling backup commit before a reset which would have \nhelped me.  Unfortunately there is currently no good way to hook into \ngit reset.\n\nThings I noticed in the process:\n\n*   for recovering blobs, going through the objects itself was more\n     useful because they were all recent changes and as such I could\n     order by timestamp.  git fsck will not provide any timestamps\n     (which generally makes sense, but made it quite useless for me)\n*   Recovering from blobs is painful, it would be nice if git reset\n     --hard made a dangling dummy commit before :)\n*   There is no pre-commit hook which could be used to implement the\n     previous suggestion.\n\nWould it make sense to introduce a `pre-commit` hook for this sort of \nthing or even create a dummy commit by default?  I did a quick googling \naround and it looks like I was not the first person who made this \nmistake.  Github's windows client even creates dangling backup commits \nin what appears to be fixed time intervals.\n\nI understand that ultimately this was a user error on my part, but it \nseems like a small change that could save a lot of frustration.\n\n\nRegards,\nArmin\n"},{"id":"256146","messageId":"CACBZZX4NkkMymnG5ZWtO1ya2xzVhxuqh4d3tU2U+mPU49n=m8g@mail.gmail.com","threadId":"38572","inReplyTo":"54E1C96D.2080109@active-4.com","subject":"Re: Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2015-02-16T12:09:36Z","receivedAt":"2015-02-16T12:09:36Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher\n<armin.ronacher@active-4.com> wrote:\n> Long story short: I failed big time yesterday with accidentally executing\n> git reset hard in the wrong terminal window but managed to recover my\n> changes from the staging area by manually examining blobs touched recently.\n>\n> After that however I figured I might want to add a precaution for myself\n> that would have helped there.  git fsck is quite nice, but unfortunately it\n> does not help if you do not have a commit.  So I figured it might be nice to\n> create a dangling backup commit before a reset which would have helped me.\n> Unfortunately there is currently no good way to hook into git reset.\n>\n> Things I noticed in the process:\n>\n> *   for recovering blobs, going through the objects itself was more\n>     useful because they were all recent changes and as such I could\n>     order by timestamp.  git fsck will not provide any timestamps\n>     (which generally makes sense, but made it quite useless for me)\n> *   Recovering from blobs is painful, it would be nice if git reset\n>     --hard made a dangling dummy commit before :)\n> *   There is no pre-commit hook which could be used to implement the\n>     previous suggestion.\n>\n> Would it make sense to introduce a `pre-commit` hook for this sort of thing\n> or even create a dummy commit by default?  I did a quick googling around and\n> it looks like I was not the first person who made this mistake.  Github's\n> windows client even creates dangling backup commits in what appears to be\n> fixed time intervals.\n>\n> I understand that ultimately this was a user error on my part, but it seems\n> like a small change that could save a lot of frustration.\n\nSomething like \"can we have a hook for every change in the working\ntree\" has come up in the past, but has been defeated by performance\nconcerns. \"git reset --hard\" is a low-level-ish operation, and it's\nreally useful to be able to quickly reset the working tree to some\nstate no matter what, and without creating extra commits or whatever.\n\nWe should definitely make recovery like this harder, but is there a\nreason for why you don't use \"git reset --keep\" instead of --hard?\nIt'll keep any local changes to your index/staging area, and reset the\nfiles that don't conflict, if there's any conflicts the operation will\nbe aborted.\n\nIf we created such hooks for \"git reset --hard\" we'd just need to\nexpose some other thing as that low-level operation (and break scripts\nthat already rely on it doing the minimal \"yes I want to change the\ntree no matter what\" thing), and then we'd just be back to square one\nin a few years when users started using \"git reset --really-hard\" (or\nwhatever the flag would be).\n"},{"id":"256147","messageId":"CACBZZX7Kjf2owiAyVzRVMs36Vj4-aYVgQ13amiJRHH91HW3RWA@mail.gmail.com","threadId":"38572","inReplyTo":"CACBZZX4NkkMymnG5ZWtO1ya2xzVhxuqh4d3tU2U+mPU49n=m8g@mail.gmail.com","subject":"Re: Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2015-02-16T12:10:33Z","receivedAt":"2015-02-16T12:10:33Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Feb 16, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher\n> <armin.ronacher@active-4.com> wrote:\n>> Long story short: I failed big time yesterday with accidentally executing\n>> git reset hard in the wrong terminal window but managed to recover my\n>> changes from the staging area by manually examining blobs touched recently.\n>>\n>> After that however I figured I might want to add a precaution for myself\n>> that would have helped there.  git fsck is quite nice, but unfortunately it\n>> does not help if you do not have a commit.  So I figured it might be nice to\n>> create a dangling backup commit before a reset which would have helped me.\n>> Unfortunately there is currently no good way to hook into git reset.\n>>\n>> Things I noticed in the process:\n>>\n>> *   for recovering blobs, going through the objects itself was more\n>>     useful because they were all recent changes and as such I could\n>>     order by timestamp.  git fsck will not provide any timestamps\n>>     (which generally makes sense, but made it quite useless for me)\n>> *   Recovering from blobs is painful, it would be nice if git reset\n>>     --hard made a dangling dummy commit before :)\n>> *   There is no pre-commit hook which could be used to implement the\n>>     previous suggestion.\n>>\n>> Would it make sense to introduce a `pre-commit` hook for this sort of thing\n>> or even create a dummy commit by default?  I did a quick googling around and\n>> it looks like I was not the first person who made this mistake.  Github's\n>> windows client even creates dangling backup commits in what appears to be\n>> fixed time intervals.\n>>\n>> I understand that ultimately this was a user error on my part, but it seems\n>> like a small change that could save a lot of frustration.\n>\n> Something like \"can we have a hook for every change in the working\n> tree\" has come up in the past, but has been defeated by performance\n> concerns. \"git reset --hard\" is a low-level-ish operation, and it's\n> really useful to be able to quickly reset the working tree to some\n> state no matter what, and without creating extra commits or whatever.\n>\n> We should definitely make recovery like this harder, but is there a\n> reason for why you don't use \"git reset --keep\" instead of --hard?\n> It'll keep any local changes to your index/staging area, and reset the\n> files that don't conflict, if there's any conflicts the operation will\n> be aborted.\n\n\"Recovery like this easier\", i.e. make it easier to get back\npreviously staged commits / blobs.\n\n> If we created such hooks for \"git reset --hard\" we'd just need to\n> expose some other thing as that low-level operation (and break scripts\n> that already rely on it doing the minimal \"yes I want to change the\n> tree no matter what\" thing), and then we'd just be back to square one\n> in a few years when users started using \"git reset --really-hard\" (or\n> whatever the flag would be).\n"},{"id":"256148","messageId":"CACsJy8B3wT5r+bSNHjEtwMcx6aVBGS9Ff++w5JU0NFN=KX4V=A@mail.gmail.com","threadId":"38572","inReplyTo":"CACBZZX7Kjf2owiAyVzRVMs36Vj4-aYVgQ13amiJRHH91HW3RWA@mail.gmail.com","subject":"Re: Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-16T12:37:40Z","receivedAt":"2015-02-16T12:37:40Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 16, 2015 at 7:10 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n>> We should definitely make recovery like this harder, but is there a\n>> reason for why you don't use \"git reset --keep\" instead of --hard?\n>> It'll keep any local changes to your index/staging area, and reset the\n>> files that don't conflict, if there's any conflicts the operation will\n>> be aborted.\n>\n> \"Recovery like this easier\", i.e. make it easier to get back\n> previously staged commits / blobs.\n\nI started with git-undo (or what's its name) a while back (*). The\nidea is for dangerous commands like this we could save some data back,\nwhich would be pruned after some time. Saving stuff in index is quite\neasy because they are already in object database. For this reset\n--hard, we may need to hash/store some more blobs. I think it's worth\nthe safety. Not sure if anyone's interested in continuing that work.\n\n(*) found it: http://thread.gmane.org/gmane.comp.version-control.git/231621/focus=231879\n-- \nDuy\n"},{"id":"256150","messageId":"54E1F0AF.1070403@active-4.com","threadId":"38572","inReplyTo":"CACBZZX4NkkMymnG5ZWtO1ya2xzVhxuqh4d3tU2U+mPU49n=m8g@mail.gmail.com","subject":"Re: Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Armin Ronacher","fromEmail":"armin.ronacher@active-4.com","sentAt":"2015-02-16T13:29:19Z","receivedAt":"2015-02-16T13:29:19Z","isPatch":false,"sender":{"key":"armin.ronacher@active-4.com","avatar":"https://gravatar.com/avatar/161ace72b12acb2f7e0db38599b74aca8f054dbdc3aae445d0d79cebb537950f?d=mp&s=160"},"body":"Hi,\n\nOn 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:\n> We should definitely make recovery like this harder, but is there a\n> reason for why you don't use \"git reset --keep\" instead of --hard?\nThis was only the second time in years of git usage that the reset was \nincorrectly done.  I suppose at this point I might try to retrain my \nmuscle memory to type something else :)\n\n> If we created such hooks for \"git reset --hard\" we'd just need to\n> expose some other thing as that low-level operation (and break scripts\n> that already rely on it doing the minimal \"yes I want to change the\n> tree no matter what\" thing), and then we'd just be back to square one\n> in a few years when users started using \"git reset --really-hard\" (or\n> whatever the flag would be).\nI don't think that's necessary, I don't think it would make the \noperation much slower to just make a dangling commit and write out a few \nblobs.  The garbage collect will soon enough take care of that data \nanyways.  But I guess that would need testing on large trees to see how \nbad that goes.\n\nI might look into the git undo thing that was mentioned.\n\n\nRegards,\nArmin\n"},{"id":"256263","messageId":"54E45F74.6080907@drmicha.warpmail.net","threadId":"38572","inReplyTo":"54E1F0AF.1070403@active-4.com","subject":"Re: Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-18T09:46:28Z","receivedAt":"2015-02-18T09:46:28Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Armin Ronacher venit, vidit, dixit 16.02.2015 14:29:\n> Hi,\n> \n> On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:\n>> We should definitely make recovery like this harder, but is there a\n>> reason for why you don't use \"git reset --keep\" instead of --hard?\n> This was only the second time in years of git usage that the reset was \n> incorrectly done.  I suppose at this point I might try to retrain my \n> muscle memory to type something else :)\n> \n>> If we created such hooks for \"git reset --hard\" we'd just need to\n>> expose some other thing as that low-level operation (and break scripts\n>> that already rely on it doing the minimal \"yes I want to change the\n>> tree no matter what\" thing), and then we'd just be back to square one\n>> in a few years when users started using \"git reset --really-hard\" (or\n>> whatever the flag would be).\n> I don't think that's necessary, I don't think it would make the \n> operation much slower to just make a dangling commit and write out a few \n> blobs.  The garbage collect will soon enough take care of that data \n> anyways.  But I guess that would need testing on large trees to see how \n> bad that goes.\n> \n> I might look into the git undo thing that was mentioned.\n> \n> \n> Regards,\n> Armin\n> \n\nAre you concerned about the index only, not unstaged worktree changes?\n\nIn this case, keeping a reflog for the index may help, and it would\nsomehow fit into the overall concept.\n\nOtherwise, we would basically need a full stash before a hard reset.\nThat's not the first time where we could need a distinction between\n\"command run by user\" and \"command run by script\". For the former, we\ncould allow overriding default options, re-aliasing internal commands,\nadding expensive safety hooks. For the latter we can't.\n\nIt's just that we don't have such a concept yet (other than checking tty).\n\nMichael\n"},{"id":"256341","messageId":"54E5C27E.9060109@drmicha.warpmail.net","threadId":"38572","inReplyTo":"19A600EC-080C-48F1-A949-9A32AFC247E7@gmail.com","subject":"Re: Experience with Recovering From User Error (And suggestions for improvements)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-19T11:01:18Z","receivedAt":"2015-02-19T11:01:18Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Kyle J. McKay venit, vidit, dixit 19.02.2015 02:17:\n> On Feb 18, 2015, at 01:46, Michael J Gruber wrote:\n>> Armin Ronacher venit, vidit, dixit 16.02.2015 14:29:\n>>> Hi,\n>>>\n>>> On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:\n>>>> We should definitely make recovery like this harder, but is there a\n>>>> reason for why you don't use \"git reset --keep\" instead of --hard?\n>>> This was only the second time in years of git usage that the reset  \n>>> was\n>>> incorrectly done.  I suppose at this point I might try to retrain my\n>>> muscle memory to type something else :)\n>>>\n>>>> If we created such hooks for \"git reset --hard\" we'd just need to\n>>>> expose some other thing as that low-level operation (and break  \n>>>> scripts\n>>>> that already rely on it doing the minimal \"yes I want to change the\n>>>> tree no matter what\" thing), and then we'd just be back to square  \n>>>> one\n>>>> in a few years when users started using \"git reset --really- \n>>>> hard\" (or\n>>>> whatever the flag would be).\n>>> I don't think that's necessary, I don't think it would make the\n>>> operation much slower to just make a dangling commit and write out  \n>>> a few\n>>> blobs.  The garbage collect will soon enough take care of that data\n>>> anyways.  But I guess that would need testing on large trees to see  \n>>> how\n>>> bad that goes.\n>>>\n>>> I might look into the git undo thing that was mentioned.\n>>>\n>>> Regards,\n>>> Armin\n>>>\n>>\n>> Are you concerned about the index only, not unstaged worktree changes?\n>>\n>> In this case, keeping a reflog for the index may help, and it would\n>> somehow fit into the overall concept.\n> \n> There was this concept of a git stash checkpoint to save work in  \n> progress without creating a normal commit that I read about some time  \n> ago (blog? Git book? -- don't recall) that was basically just this:\n> \n>    git stash save\n>    git stash apply\n> \n> The problem with that is that it touches the working tree and can  \n> trigger rebuilds etc.  However, when I ran across the undocumented  \n> \"git stash create\" command I was able to write a simple git-checkpoint  \n> script [1] that creates a new stash entry without touching the index  \n> or working tree which I find quite handy from time to time.\n\nI think that would make for a nice additional command/mode that we could\nsupport for git-stash.sh. Alle the pieces are there.\n\n> So I think that what Armin originally asked for (create a dangling  \n> commit of changes before reset --hard) could be accomplished simply by  \n> running:\n> \n>    git checkpoint && git stash drop\n> \n>> Otherwise, we would basically need a full stash before a hard reset.\n>> That's not the first time where we could need a distinction between\n>> \"command run by user\" and \"command run by script\". For the former, we\n>> could allow overriding default options, re-aliasing internal commands,\n>> adding expensive safety hooks. For the latter we can't.\n>>\n>> It's just that we don't have such a concept yet (other than checking  \n>> tty).\n> \n> But of course plugging that into git reset somehow is indeed the  \n> problem since you cannot alias/redefine git commands.\n> \n> -Kyle\n> \n> [1] https://gist.github.com/mackyle/83b1ba13e263356bdab0\n\nAlso, \"git stash create\" does the tree creation and object creation that\nwe wanted to avoid at least for scripts.\n\nAnd \"git reset --hard-but-safe\" suffers from the user education problems\nthat have been mentioned already.\n\nMichael\n"},{"id":"256345","messageId":"dbd1aae0508bd72dc3b21fabda4c420eef487720.1424349039.git.git@drmicha.warpmail.net","threadId":"38572","inReplyTo":"54E5C27E.9060109@drmicha.warpmail.net","subject":"[RFD/PATCH] stash: introduce checkpoint mode","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-19T12:34:03Z","receivedAt":"2015-02-19T12:34:03Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"\"git stash save\" performs the steps \"create-store-reset\". Often,\nusers try to use \"stash save\" as a way to to save their current state\n(index, worktree) before an operation like \"checkout/reset --patch\" they\ndon't feel confident about, and are forced to do \"git stash save && git\nstash apply\".\n\nProvide an extra mode that does \"create-store\" only without the reset,\nso that one can \"ceckpoint\" the sate and keep working on it.\n\nSuggested-by: \"Kyle J. McKay\" <mackyle@gmail.com>\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n\nNotes:\n    I'm not sure about how to best expose this mode:\n    \n    git stash checkpoint\n    git stash save --checkpoint\n    \n    Maybe it is best to document the former and rename \"--checkpoint\"\n    to \"--no-reset\"?\n    \n    Also, a \"safe return\" to a checkpoint probably requires\n    \n    git reset --hard && git stash pop\n    \n    although \"git stash pop\" will do in many cases. Should we provide a shortcut\n    \"restore\" which does the reset-and-pop?\n\n git-stash.sh | 13 +++++++++++++\n 1 file changed, 13 insertions(+)\n\ndiff --git a/git-stash.sh b/git-stash.sh\nindex d4cf818..42f140c 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -193,12 +193,16 @@ store_stash () {\n }\n \n save_stash () {\n+\tcheckpoint=\n \tkeep_index=\n \tpatch_mode=\n \tuntracked=\n \twhile test $# != 0\n \tdo\n \t\tcase \"$1\" in\n+\t\t-c|--checkpoint)\n+\t\t\tcheckpoint=t\n+\t\t\t;;\n \t\t-k|--keep-index)\n \t\t\tkeep_index=t\n \t\t\t;;\n@@ -267,6 +271,11 @@ save_stash () {\n \tdie \"$(gettext \"Cannot save the current status\")\"\n \tsay Saved working directory and index state \"$stash_msg\"\n \n+\tif test -n \"$checkpoint\"\n+\tthen\n+\t\texit 0\n+\tfi\n+\n \tif test -z \"$patch_mode\"\n \tthen\n \t\tgit reset --hard ${GIT_QUIET:+-q}\n@@ -576,6 +585,10 @@ save)\n \tshift\n \tsave_stash \"$@\"\n \t;;\n+checkpoint)\n+\tshift\n+\tsave_stash \"--checkpoint\" \"$@\"\n+\t;;\n apply)\n \tshift\n \tapply_stash \"$@\"\n-- \n2.3.0.191.ge77e8b9\n"},{"id":"256350","messageId":"8AAD6FE6-75C1-4BA2-8667-4DF8BF6B1EE4@gmail.com","threadId":"38572","inReplyTo":"dbd1aae0508bd72dc3b21fabda4c420eef487720.1424349039.git.git@drmicha.warpmail.net","subject":"Re: [RFD/PATCH] stash: introduce checkpoint mode","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-02-19T13:58:14Z","receivedAt":"2015-02-19T13:58:14Z","isPatch":true,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Feb 19, 2015, at 04:34, Michael J Gruber wrote:\n\n> \"git stash save\" performs the steps \"create-store-reset\". Often,\n> users try to use \"stash save\" as a way to to save their current state\n> (index, worktree) before an operation like \"checkout/reset --patch\"  \n> they\n> don't feel confident about, and are forced to do \"git stash save &&  \n> git\n> stash apply\".\n>\n> Provide an extra mode that does \"create-store\" only without the reset,\n> so that one can \"ceckpoint\" the sate and keep working on it.\n\ns/sate/state/\n\n> Suggested-by: \"Kyle J. McKay\" <mackyle@gmail.com>\n> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n> ---\n>\n> Notes:\n>    I'm not sure about how to best expose this mode:\n>\n>    git stash checkpoint\n>    git stash save --checkpoint\n>\n>    Maybe it is best to document the former and rename \"--checkpoint\"\n>    to \"--no-reset\"?\n\nOnce the user figures out that \"save\" is really \"save-and-reset\" I  \nthink \"--no-reset\" makes more sense.\n\nIt certainly seems more discoverable via an explicit \"checkpoint\"  \ncommand though, but that's really just an alias so maybe it's better  \nleft up to the user to make one.\n\nThere would need to be some updated docs (git-stash.txt) to go with  \nthe change...\n\n>    Also, a \"safe return\" to a checkpoint probably requires\n>\n>    git reset --hard && git stash pop\n>\n>    although \"git stash pop\" will do in many cases. Should we provide  \n> a shortcut\n>    \"restore\" which does the reset-and-pop?\n\nWhat about a shortcut to \"reset-and-apply\" as well?\n\nI have often been frustrated when \"git stash apply\" refuses to work  \nbecause I have changes that would be stepped on and there's no --force  \noption like git checkout has.  I end up doing a reset just so I can  \nrun stash apply.\n\nWhat about if git stash apply/pop grokked a --force option?  That  \nwould seem to eliminate the need for a \"reset-and-pop\"/\"reset-and- \napply\" shortcut while also being useful to non-checkpoint stashes as  \nwell.\n\n> git-stash.sh | 13 +++++++++++++\n> 1 file changed, 13 insertions(+)\n>\n> diff --git a/git-stash.sh b/git-stash.sh\n> index d4cf818..42f140c 100755\n> --- a/git-stash.sh\n> +++ b/git-stash.sh\n> @@ -193,12 +193,16 @@ store_stash () {\n> }\n>\n> save_stash () {\n> +\tcheckpoint=\n> \tkeep_index=\n> \tpatch_mode=\n> \tuntracked=\n> \twhile test $# != 0\n> \tdo\n> \t\tcase \"$1\" in\n> +\t\t-c|--checkpoint)\n> +\t\t\tcheckpoint=t\n> +\t\t\t;;\n> \t\t-k|--keep-index)\n> \t\t\tkeep_index=t\n> \t\t\t;;\n> @@ -267,6 +271,11 @@ save_stash () {\n> \tdie \"$(gettext \"Cannot save the current status\")\"\n> \tsay Saved working directory and index state \"$stash_msg\"\n>\n> +\tif test -n \"$checkpoint\"\n> +\tthen\n> +\t\texit 0\n> +\tfi\n> +\n> \tif test -z \"$patch_mode\"\n> \tthen\n> \t\tgit reset --hard ${GIT_QUIET:+-q}\n> @@ -576,6 +585,10 @@ save)\n> \tshift\n> \tsave_stash \"$@\"\n> \t;;\n> +checkpoint)\n> +\tshift\n> +\tsave_stash \"--checkpoint\" \"$@\"\n> +\t;;\n> apply)\n> \tshift\n> \tapply_stash \"$@\"\n> -- \n\nOtherwise this looks good.  A very small change to add the  \nfunctionality.\n\n-Kyle\n"},{"id":"256355","messageId":"xmqq7fvd23mw.fsf@gitster.dls.corp.google.com","threadId":"38572","inReplyTo":"8AAD6FE6-75C1-4BA2-8667-4DF8BF6B1EE4@gmail.com","subject":"Re: [RFD/PATCH] stash: introduce checkpoint mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-19T17:49:11Z","receivedAt":"2015-02-19T17:49:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kyle J. McKay\" <mackyle@gmail.com> writes:\n\n> What about a shortcut to \"reset-and-apply\" as well?\n>\n> I have often been frustrated when \"git stash apply\" refuses to work\n> because I have changes that would be stepped on and there's no --force\n> option like git checkout has.  I end up doing a reset just so I can\n> run stash apply.\n\nDoesn't that cut both ways, though?\n\nA single step short-cut, done in any way other than a more explicit\nway such as \"git reset --hard && git stash apply\" (e.g. \"git stash\nreset-and-apply\" or \"git stash apply --force\") that makes it crystal\nclear that the user _is_ discarding, has a risk of encouraging users\nto form a dangerous habit of invoking the short-cut without thinking\nand leading to \"oops, I didn't mean that!\".\n"},{"id":"256372","messageId":"04CB0145-FE99-46EB-8430-069E05DF31EB@gmail.com","threadId":"38572","inReplyTo":"xmqq7fvd23mw.fsf@gitster.dls.corp.google.com","subject":"Re: [RFD/PATCH] stash: introduce checkpoint mode","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-02-19T23:43:16Z","receivedAt":"2015-02-19T23:43:16Z","isPatch":true,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Feb 19, 2015, at 09:49, Junio C Hamano wrote:\n> \"Kyle J. McKay\" <mackyle@gmail.com> writes:\n>\n>> What about a shortcut to \"reset-and-apply\" as well?\n>>\n>> I have often been frustrated when \"git stash apply\" refuses to work\n>> because I have changes that would be stepped on and there's no -- \n>> force\n>> option like git checkout has.  I end up doing a reset just so I can\n>> run stash apply.\n>\n> Doesn't that cut both ways, though?\n>\n> A single step short-cut, done in any way other than a more explicit\n> way such as \"git reset --hard && git stash apply\" (e.g. \"git stash\n> reset-and-apply\" or \"git stash apply --force\") that makes it crystal\n> clear that the user _is_ discarding, has a risk of encouraging users\n> to form a dangerous habit of invoking the short-cut without thinking\n> and leading to \"oops, I didn't mean that!\".\n\nDoes that reasoning not also apply to the plethora of commands that  \ntake \"--force\" already?\n\nI didn't check them all, but tag, checkout, push and branch  \nimmediately come to mind.  Why is it okay for all those other commands  \nto have a --force mode, but not git stash?\n"}]}