git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
MRMarkus Raab <mailinglists@markus-raab.org>
Date
Apr 20, 2025, 13:48 UTC
Message-ID
<95f731c2-ad2f-40cc-a7d9-85f52cc16389@markus-raab.org>
In-Reply-To
<aAT4kHFPEb5qwoMv@tapette.crustytoothpaste.net>
Dear Brian,
Thanks for the quick reply.

Unfortunately, I forgot an essential line in my first e-mail, thus I've resent my e-mail shortly later again.

To "fix" your shell script (make the files get lost), git stash pop should be inserted before the last line:

---- #!/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 stash pop git cherry-pick --abort ----

So it is basically about unexpected adding of files, that got discarded via a "git cherry-pick --abort".

Btw. the files can be recovered via

---- #!/usr/bin/env bash

headcommit="$(git log --format=format:%H)"
headcommitobject=".git/objects/${headcommit:0:2}/${headcommit:2}"
mkdir recovering_lost_files
find .git/objects/ -type f -daystart -ctime 0|while read -r path
do
     obj="${path#.git/objects/}"
     obj="${obj/\/}"
     git cat-file -p $obj > recovering_lost_files/$obj
done
----

best regards, Markus

Am 20.04.25 um 15:37 schrieb brian m. carlson:
Show 56 quoted lines
> 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?
-- 
Best regards,
Markus Raab
Previous: brian m. carlsonNext: Junio C Hamano
Message 3 of 5 in “unwanted interaction of git stash and cherry-pick --abort”
  1. Markus RaabApr 20, 2025
  2. brian m. carlsonApr 20, 2025
  3. Markus RaabApr 20, 2025
  4. Junio C HamanoApr 20, 2025
  5. Markus RaabApr 21, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.