Re: unwanted interaction of git stash and cherry-pick --abort

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 20, 2025, 13:37 UTC
Message-ID: <aAT4kHFPEb5qwoMv@tapette.crustytoothpaste.net>
In-Reply-To: <d8c1df4e-a4d7-4c4c-be44-b13de3d9ffea@markus-raab.org>

On 2025-04-20 at 13:14:31, Markus Raab wrote:

Show 13 quoted lines

> 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 ----

Show 16 quoted lines

> 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