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

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

From
MRMarkus Raab <mailinglists@markus-raab.org>
Date
Apr 20, 2025, 13:18 UTC
Message-ID
<13ce78d9-9afc-4bde-8c52-bbbae80cd707@markus-raab.org>
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 stash pop 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 ;(

[System Info] git version: git version 2.39.5 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64 compiler info: gnuc: 12.2 libc info: glibc: 2.36 $SHELL (typically, interactive shell): /bin/zsh

[Enabled Hooks]
-- 
Best regards,
Markus Raab
Message 1 of 1 in “unwanted interaction of git stash and cherry-pick --abort”
  1. Markus RaabApr 20, 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.