{"thread":{"id":"63316","subject":"unwanted interaction of git stash and cherry-pick --abort","startedAt":"2025-04-20T13:21:26Z","lastAt":"2025-04-21T05:38:16Z","messageCount":5,"participants":["Markus Raab","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"516410","messageId":"d8c1df4e-a4d7-4c4c-be44-b13de3d9ffea@markus-raab.org","threadId":"63316","inReplyTo":null,"subject":"unwanted interaction of git stash and cherry-pick --abort","fromName":"Markus Raab","fromEmail":"mailinglists@markus-raab.org","sentAt":"2025-04-20T13:14:31Z","receivedAt":"2025-04-20T13:21:26Z","isPatch":false,"sender":{"key":"mailinglists@markus-raab.org","avatar":null},"body":"Dear git maintainers,\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\ngit init-db\ngit commit --allow-empty # needed for git stash later\necho a > a\necho b > b\ngit add a b # some arbitrary files with content\ngit stash\ngit cherry-pick 170bbe5 # any commit that cannot be applied, e.g. the \ninitial commit here\ngit cherry-pick --abort\n\nWhat did you expect to happen? (Expected behavior)\n\nThat a and b are still there or I am somehow informed that the files a \nand b would get lost.\n\nWhat happened instead? (Actual behavior)\n\nThe files a and b are lost.\n\nWhat's different between what you expected and what actually happened?\n\nLoss of data.\n\nAnything else you want to add:\n\nEverything fine, only the content of a and b is lost ;(\n\n\n[System Info]\ngit version:\ngit version 2.39.5\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64\ncompiler info: gnuc: 12.2\nlibc info: glibc: 2.36\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\n\n-- \nBest regards,\nMarkus Raab\n\n"},{"id":"516411","messageId":"aAT4kHFPEb5qwoMv@tapette.crustytoothpaste.net","threadId":"63316","inReplyTo":"d8c1df4e-a4d7-4c4c-be44-b13de3d9ffea@markus-raab.org","subject":"Re: unwanted interaction of git stash and cherry-pick --abort","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-04-20T13:37:20Z","receivedAt":"2025-04-20T13:37:29Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-04-20 at 13:14:31, Markus Raab wrote:\n> Dear git maintainers,\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> git init-db\n> git commit --allow-empty # needed for git stash later\n> echo a > a\n> echo b > b\n> git add a b # some arbitrary files with content\n> git stash\n> git cherry-pick 170bbe5 # any commit that cannot be applied, e.g. the\n> initial commit here\n> git cherry-pick --abort\n\nHere's the exact shell script I used to test this case:\n\n----\n#!/bin/sh\n\ngit init-db --object-format=sha256\ngit commit --allow-empty -m +\noid=$(git rev-parse HEAD)\necho a > a\necho b > b\ngit add a b # some arbitrary files with content\ngit stash\ngit cherry-pick $oid\ngit cherry-pick --abort\n----\n\n> What did you expect to happen? (Expected behavior)\n> \n> That a and b are still there or I am somehow informed that the files a and b\n> would get lost.\n> \n> What happened instead? (Actual behavior)\n> \n> The files a and b are lost.\n> \n> What's different between what you expected and what actually happened?\n> \n> Loss of data.\n> \n> Anything else you want to add:\n> \n> Everything fine, only the content of a and b is lost ;(\n\nI don't think these are lost.  Because they were added, they were saved\nin the stash with `git stash` and can be recovered from there with `git\nstash pop`.  `git cherry-pick` won't have done anything to modify the\nstashes and in my test case, I can see `git stash list -p` shows both of\nthose files.\n\nIs this also the case for you or is your situation maybe a little\ndifferent?\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"516412","messageId":"95f731c2-ad2f-40cc-a7d9-85f52cc16389@markus-raab.org","threadId":"63316","inReplyTo":"aAT4kHFPEb5qwoMv@tapette.crustytoothpaste.net","subject":"Re: unwanted interaction of git stash and cherry-pick --abort","fromName":"Markus Raab","fromEmail":"mailinglists@markus-raab.org","sentAt":"2025-04-20T13:48:24Z","receivedAt":"2025-04-20T13:48:27Z","isPatch":false,"sender":{"key":"mailinglists@markus-raab.org","avatar":null},"body":"Dear Brian,\n\nThanks for the quick reply.\n\nUnfortunately, I forgot an essential line in my first e-mail, thus I've \nresent my e-mail shortly later again.\n\nTo \"fix\" your shell script (make the files get lost), git stash pop \nshould be inserted before the last line:\n\n----\n#!/bin/sh\n\ngit init-db --object-format=sha256\ngit commit --allow-empty -m +\noid=$(git rev-parse HEAD)\necho a > a\necho b > b\ngit add a b # some arbitrary files with content\ngit stash\ngit cherry-pick $oid\ngit stash pop\ngit cherry-pick --abort\n----\n\nSo it is basically about unexpected adding of files, that got discarded \nvia a \"git cherry-pick --abort\".\n\nBtw. the files can be recovered via\n\n----\n#!/usr/bin/env bash\n\nheadcommit=\"$(git log --format=format:%H)\"\nheadcommitobject=\".git/objects/${headcommit:0:2}/${headcommit:2}\"\nmkdir recovering_lost_files\nfind .git/objects/ -type f -daystart -ctime 0|while read -r path\ndo\n     obj=\"${path#.git/objects/}\"\n     obj=\"${obj/\\/}\"\n     git cat-file -p $obj > recovering_lost_files/$obj\ndone\n----\n\nbest regards,\nMarkus\n\n\nAm 20.04.25 um 15:37 schrieb brian m. carlson:\n> On 2025-04-20 at 13:14:31, Markus Raab wrote:\n>> Dear git maintainers,\n>>\n>> What did you do before the bug happened? (Steps to reproduce your issue)\n>>\n>> git init-db\n>> git commit --allow-empty # needed for git stash later\n>> echo a > a\n>> echo b > b\n>> git add a b # some arbitrary files with content\n>> git stash\n>> git cherry-pick 170bbe5 # any commit that cannot be applied, e.g. the\n>> initial commit here\n>> git cherry-pick --abort\n> \n> Here's the exact shell script I used to test this case:\n> \n> ----\n> #!/bin/sh\n> \n> git init-db --object-format=sha256\n> git commit --allow-empty -m +\n> oid=$(git rev-parse HEAD)\n> echo a > a\n> echo b > b\n> git add a b # some arbitrary files with content\n> git stash\n> git cherry-pick $oid\n> git cherry-pick --abort\n> ----\n> \n>> What did you expect to happen? (Expected behavior)\n>>\n>> That a and b are still there or I am somehow informed that the files a and b\n>> would get lost.\n>>\n>> What happened instead? (Actual behavior)\n>>\n>> The files a and b are lost.\n>>\n>> What's different between what you expected and what actually happened?\n>>\n>> Loss of data.\n>>\n>> Anything else you want to add:\n>>\n>> Everything fine, only the content of a and b is lost ;(\n> \n> I don't think these are lost.  Because they were added, they were saved\n> in the stash with `git stash` and can be recovered from there with `git\n> stash pop`.  `git cherry-pick` won't have done anything to modify the\n> stashes and in my test case, I can see `git stash list -p` shows both of\n> those files.\n> \n> Is this also the case for you or is your situation maybe a little\n> different?\n\n\n-- \nBest regards,\nMarkus Raab\n"},{"id":"516414","messageId":"xmqqjz7e8rxa.fsf@gitster.g","threadId":"63316","inReplyTo":"95f731c2-ad2f-40cc-a7d9-85f52cc16389@markus-raab.org","subject":"Re: unwanted interaction of git stash and cherry-pick --abort","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-20T21:05:37Z","receivedAt":"2025-04-20T21:05:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Markus Raab <mailinglists@markus-raab.org> writes:\n\n> Dear Brian,\n>\n> Thanks for the quick reply.\n>\n> Unfortunately, I forgot an essential line in my first e-mail, thus\n> I've resent my e-mail shortly later again.\n>\n> To \"fix\" your shell script (make the files get lost), git stash pop\n> should be inserted before the last line:\n>\n> ----\n> #!/bin/sh\n>\n> git init-db --object-format=sha256\n> git commit --allow-empty -m +\n> oid=$(git rev-parse HEAD)\n> echo a > a\n> echo b > b\n> git add a b # some arbitrary files with content\n> git stash\n> git cherry-pick $oid\n> git stash pop\n> git cherry-pick --abort\n> ----\n\nSo, this is not limited to stash at all.\n\nWhen you start \"cherry-pick\", which cannot complete without your\nhelp (most often, this happens when the cherry-picked change\nconflicts with what you have in the current commit), the command\nstops and gives control back.\n\nAt that point, it is up to you to do anything to bring your index\ninto a shape that you desire the \"cherry-picked\" commit to have.\nYou'd do so by editing working tree files (often with conflicts),\ncreating new files, removing unneeded files, etc., and then updating\nyour index with these changes, and then \"cherry-pick --continue\" to\nconclude.\n\nOr, after mucking your working tree and index to \"correct\" the\nstalled \"cherry-pick\", you may decide that it is not a good idea to\ncherry-pick the commit after all.  You say \"cherry-pick --abort\" and\nyou expect your index to be clean relative to HEAD, and working tree\nfiles also adjusted for it.  You may have edited existing working\ntree files, created new files, or removed files that you thought\nunneeded, before deciding that it is not a good idea to perform this\ncherry-pick.  And the way to ask Git to revert all of these changes\nyou made to your index and your working tree file, and get you out\nof the \"cherry-picking\" state, is to run \"cherry-pick --abort\".\n\nInstead of doing \"git stash pop\" there, you could have added\narbitrary files with content, or edited working tree files, or\nany other changes manually, and \"cherry-pick --abort\" would have\nremoved such changes to your index and your working tree files, just\nthe same way.\n\nSo there is nothing unexpected.\n\nThere is another aspect in this story.\n\n\"git stash pop\" will remove the stash entry after updating your\nindex and your working tree files, and unless you save them away\nelsewhere, if you make further changes to these files, there is no\neasy way to get that exact change you took out of the stash entry\nback.\n\nAnd this is not limited to \"cherry-pick --abort\".\n\nYou can edit these files manually (totally outside of Git), remove\nthem, or ask Git to give you a clean slate with \"git reset --hard\".\n\nSo one lesson we can learn from this episode is\n\n    Never use \"git stash pop\" WHEN IT IS POSSIBLE YOU MAY LATER\n    CHANGE YOUR MIND.  \"pop\" applies and then drops the stash entry,\n    so what you will have in your index and working tree will become\n    the ONLY copy of the change you previously stashed.\n\nIf you are in doubt, use \"git stash apply\" instead.  The stash entry\nwill stay, so when you decide to get rid of the change you pulled\nout of the stash entry into the working tree, you can safely do so\nwith \"reset --hard\" and nothing is lost.\n\nOf course, you need to remember at some point to drop the entry you\nno longer need with \"git stash drop\" if you take that approach.\n\nHTH.\n"},{"id":"516416","messageId":"033e4524-d169-4003-9e2c-aa32797a67b5@markus-raab.org","threadId":"63316","inReplyTo":"xmqqjz7e8rxa.fsf@gitster.g","subject":"Re: unwanted interaction of git stash and cherry-pick --abort","fromName":"Markus Raab","fromEmail":"mailinglists@markus-raab.org","sentAt":"2025-04-21T05:38:13Z","receivedAt":"2025-04-21T05:38:16Z","isPatch":false,"sender":{"key":"mailinglists@markus-raab.org","avatar":null},"body":"Dear maintainers,\n\nAm 20.04.25 um 23:05 schrieb Junio C Hamano:\n> Markus Raab <mailinglists@markus-raab.org> writes:\n>> To \"fix\" your shell script (make the files get lost), git stash pop\n>> should be inserted before the last line:\n>>\n>> ----\n>> #!/bin/sh\n>>\n>> git init-db --object-format=sha256\n>> git commit --allow-empty -m +\n>> oid=$(git rev-parse HEAD)\n>> echo a > a\n>> echo b > b\n>> git add a b # some arbitrary files with content\n>> git stash\n>> git cherry-pick $oid\n>> git stash pop\n>> git cherry-pick --abort\n>> ----\n> \n> So, this is not limited to stash at all.\n\nYes, it is just how I ran into it. It is neither limited to stash nor \ncherry-pick --abort.\n\n> When you start \"cherry-pick\", which cannot complete without your\n> help (most often, this happens when the cherry-picked change\n> conflicts with what you have in the current commit), the command\n> stops and gives control back.\n\nThis is fine and expected.\n\n> At that point, it is up to you to do anything to bring your index\n> into a shape that you desire the \"cherry-picked\" commit to have.\n> You'd do so by editing working tree files (often with conflicts),\n> creating new files, removing unneeded files, etc., and then updating\n> your index with these changes, and then \"cherry-pick --continue\" to\n> conclude.\n> \n> Or, after mucking your working tree and index to \"correct\" the\n> stalled \"cherry-pick\", you may decide that it is not a good idea to\n> cherry-pick the commit after all.  You say \"cherry-pick --abort\" and\n> you expect your index to be clean relative to HEAD, and working tree\n> files also adjusted for it. \n\nWhat I additionally would have hoped for (hence this bug report) was \nsome way to undo the \"cherry-pick --abort\". A \"help for undoing\" would \nactually be helpful for many other operations, too.\n\nActually, I later on found how to undo it, so you might also consider to \ndo nothing here.\n\nBut if you want to become even more user friendly, you could also \nconsider to print a message which would help the user to recover the \nstate/files which might have been lost accidentally.\n\nE.g. \"git rebase\" could print which sha256 was the HEAD before rebase \nand \"cherry-pick --abort\" could print how to recover the added files \nthat were reset etc.\n\nOr an alternative approach would be some \"git recover-recent-files\", \n\"git recover-recent-commits\" etc. commands so that the user does not \nhave to fiddle manually in .git/objects. Similar to the \"go back in \ntime\" feature in vim (which I rarely use, though).\n\n> Instead of doing \"git stash pop\" there, you could have added\n> arbitrary files with content, or edited working tree files, or\n> any other changes manually, and \"cherry-pick --abort\" would have\n> removed such changes to your index and your working tree files, just\n> the same way.\n\nYes, it is the same and I agree the main problem was in the front of the \nkeyboard. But things like this happen ;)\n\n> \"git stash pop\" will remove the stash entry after updating your\n> index and your working tree files, and unless you save them away\n> elsewhere, if you make further changes to these files, there is no\n> easy way to get that exact change you took out of the stash entry\n> back.\n\nYes, so you could take my story as hint to improve the \"undo-ability\" of \ngit in such scenarios.\n\n> So one lesson we can learn from this episode is\n> \n>      Never use \"git stash pop\" WHEN IT IS POSSIBLE YOU MAY LATER\n>      CHANGE YOUR MIND.  \"pop\" applies and then drops the stash entry,\n>      so what you will have in your index and working tree will become\n>      the ONLY copy of the change you previously stashed.\n\nYeah, thanks to clearly state it.\n\n> Of course, you need to remember at some point to drop the entry you\n> no longer need with \"git stash drop\" if you take that approach.\n\nExactly, also a failed \"git stash pop\" won't get removed, so there \neasily accumulate \"forgotten\" things in git stashes. But much better to \nhave a bit less tidiness then lost files after \"git gc\". So I think the \nbehavior of \"git stash pop\" itself actually has good \"undo-ability\".\n\n-- \nBest regards,\nMarkus Raab\n"}]}