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

From: Markus Raab <mailinglists@markus-raab.org>
Date: Apr 21, 2025, 05:38 UTC
Message-ID: <033e4524-d169-4003-9e2c-aa32797a67b5@markus-raab.org>
In-Reply-To: <xmqqjz7e8rxa.fsf@gitster.g>

Dear maintainers,

Am 20.04.25 um 23:05 schrieb Junio C Hamano:

Show 20 quoted lines

> Markus Raab <mailinglists@markus-raab.org> writes:
>> 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, this is not limited to stash at all.

Yes, it is just how I ran into it. It is neither limited to stash nor cherry-pick --abort.

> When you start "cherry-pick", which cannot complete without your
> help (most often, this happens when the cherry-picked change
> conflicts with what you have in the current commit), the command
> stops and gives control back.

This is fine and expected.

Show 12 quoted lines

> At that point, it is up to you to do anything to bring your index
> into a shape that you desire the "cherry-picked" commit to have.
> You'd do so by editing working tree files (often with conflicts),
> creating new files, removing unneeded files, etc., and then updating
> your index with these changes, and then "cherry-pick --continue" to
> conclude.
> 
> Or, after mucking your working tree and index to "correct" the
> stalled "cherry-pick", you may decide that it is not a good idea to
> cherry-pick the commit after all.  You say "cherry-pick --abort" and
> you expect your index to be clean relative to HEAD, and working tree
> files also adjusted for it.

What I additionally would have hoped for (hence this bug report) was some way to undo the "cherry-pick --abort". A "help for undoing" would actually be helpful for many other operations, too.

Actually, I later on found how to undo it, so you might also consider to do nothing here.

But if you want to become even more user friendly, you could also consider to print a message which would help the user to recover the state/files which might have been lost accidentally.

E.g. "git rebase" could print which sha256 was the HEAD before rebase and "cherry-pick --abort" could print how to recover the added files that were reset etc.

Or an alternative approach would be some "git recover-recent-files", "git recover-recent-commits" etc. commands so that the user does not have to fiddle manually in .git/objects. Similar to the "go back in time" feature in vim (which I rarely use, though).

Show 5 quoted lines

> Instead of doing "git stash pop" there, you could have added
> arbitrary files with content, or edited working tree files, or
> any other changes manually, and "cherry-pick --abort" would have
> removed such changes to your index and your working tree files, just
> the same way.

Yes, it is the same and I agree the main problem was in the front of the keyboard. But things like this happen ;)

Show 5 quoted lines

> "git stash pop" will remove the stash entry after updating your
> index and your working tree files, and unless you save them away
> elsewhere, if you make further changes to these files, there is no
> easy way to get that exact change you took out of the stash entry
> back.

Yes, so you could take my story as hint to improve the "undo-ability" of git in such scenarios.

Show 6 quoted lines

> So one lesson we can learn from this episode is
> 
>      Never use "git stash pop" WHEN IT IS POSSIBLE YOU MAY LATER
>      CHANGE YOUR MIND.  "pop" applies and then drops the stash entry,
>      so what you will have in your index and working tree will become
>      the ONLY copy of the change you previously stashed.

Yeah, thanks to clearly state it.

> Of course, you need to remember at some point to drop the entry you
> no longer need with "git stash drop" if you take that approach.

Exactly, also a failed "git stash pop" won't get removed, so there easily accumulate "forgotten" things in git stashes. But much better to have a bit less tidiness then lost files after "git gc". So I think the behavior of "git stash pop" itself actually has good "undo-ability".

-- 
Best regards,
Markus Raab