On 2025-04-20 at 13:14:31, Markus Raab wrote: > Dear git maintainers, > > What did you do before the bug happened? (Steps to reproduce your issue) > > git init-db > git commit --allow-empty # needed for git stash later > echo a > a > echo b > b > git add a b # some arbitrary files with content > git stash > git cherry-pick 170bbe5 # any commit that cannot be applied, e.g. the > initial commit here > git cherry-pick --abort Here's the exact shell script I used to test this case: ---- #!/bin/sh git init-db --object-format=sha256 git commit --allow-empty -m + oid=$(git rev-parse HEAD) echo a > a echo b > b git add a b # some arbitrary files with content git stash git cherry-pick $oid git cherry-pick --abort ---- > What did you expect to happen? (Expected behavior) > > That a and b are still there or I am somehow informed that the files a and b > would get lost. > > What happened instead? (Actual behavior) > > The files a and b are lost. > > What's different between what you expected and what actually happened? > > Loss of data. > > Anything else you want to add: > > Everything fine, only the content of a and b is lost ;( I don't think these are lost. Because they were added, they were saved in the stash with `git stash` and can be recovered from there with `git stash pop`. `git cherry-pick` won't have done anything to modify the stashes and in my test case, I can see `git stash list -p` shows both of those files. Is this also the case for you or is your situation maybe a little different? -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
