Bug in git-stash

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

edit a file

`git add <file>`

edit the same line again

`git stash -k`

What did you expect to happen? (Expected behavior) I expect the stash to contain the diff between the staged file and the unstaged file

What happened instead? (Actual behavior) The stash contains the diff between HEAD and the unstaged file

What's different between what you expected and what actually happened? The difference is that `git stash pop` will result in a merge conflict, even though no files has been changed between stashing and unstashing.

Anything else you want to add:

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.39.5 (Apple Git-154) cpu: arm64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Darwin 23.6.0 Darwin Kernel Version 23.6.0: Fri Nov 15 15:11:49 PST 2024; root:xnu-10063.141.1.702.7~1/RELEASE_ARM64_T6020 arm64 compiler info: clang: 16.0.0 (clang-1600.0.26.6) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh

On Fri, Apr 11, 2025 at 8:29 AM Filip Skogstjärna <f.skogstjarna@gmail.com> wrote:

I think you might find the following thread instructive: https://lore.kernel.org/git/ZikMqXeDnOqK_wlq@thechases.com/

Cheers,

Hi!

This is expected behavior. From the git stash manpage:

""" All changes already added to the index are left intact. """

This is, it works just like running `git stash` but without touching the index and keeping the already staged changes in the working directory.

But still, each stash entry is two commits, one containing the state of the index and other containing the state of the working tree. You can see that in git stash manpage, in the section "DISCUSSION". This way, you can operate on them like any other commit.

More specifically, if you want the stashed changes from the index to the working directory, you can run:

git cherry-pick -n -m 2 stash

where:

-n: cherry-picks the content without creating a commit

-m 2: given that the last commit is a merge commit whose
  parents are the HEAD at the moment of stashing changes (the
  first parent) and the commit containing the state of the
  index (the second parent), apply the changes based on the
  second parent (i.e. what was in the working directory but
  not in the index)

- stash: this is the stash reference (just like any other
  reference, like branches or tags). It points to the last
  commit of the last stash entry. If you want to use other
  entry, follow the reflog syntax (i.e. stash@{1})