# Git Bug Report: 'git stash pop' always put newly added files into staging area

2 messages from 2022-02-02 to 2022-02-03. Participants: Zhuo Cheng Du.
Thread: https://gitlist.dev/t/57360

## Zhuo Cheng Du, 2022-02-02 18:50

Subject: Git Bug Report: 'git stash pop' always put newly added files into staging area
Message-ID: <CA+RO+X6Lat5-AZ+BoHwW8xzhXuNOTjQewyNAvzOjWF_Md0x_yA@mail.gmail.com>
URL: https://gitlist.dev/e/CA%2BRO%2BX6Lat5-AZ%2BBoHwW8xzhXuNOTjQewyNAvzOjWF_Md0x_yA%40mail.gmail.com

```
What did you do before the bug happened? (Steps to reproduce your issue)
1. Create a brand new file, e.g. 'touch a.py'
2. Add it to worktree with 'git add a.py'
3. stash the file with 'git stash'
4. pop the stashed change with 'git stash pop', WITHOUT the --index option

What did you expect to happen? (Expected behavior)
I expect the file 'a.py' to be in unstaged area since I did not pass
the '--index' option to 'git stash pop'

What happened instead? (Actual behavior)
The file is found in staged are are after 'git stash pop', potentially
causing merge-conflict in certain scenarios

What's different between what you expected and what actually happened?
I want the file to be found in unstaged area. The 'git stash
push'/'git stash pop' combo works as expected if the file is already
added to worktree prior to this maneuver. I think the behavior should
be consistent for brand new files as well.

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.31.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58
PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.0 (clang-1200.0.32.29)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]

```

## Zhuo Cheng Du, 2022-02-03 13:27

Subject: Re: Git Bug Report: 'git stash pop' always put newly added files into staging area
Message-ID: <CA+RO+X4GAXVEA44nqaAKVxAxxzGQkf66kLrwadw3qcsZhULJgQ@mail.gmail.com>
URL: https://gitlist.dev/e/CA%2BRO%2BX4GAXVEA44nqaAKVxAxxzGQkf66kLrwadw3qcsZhULJgQ%40mail.gmail.com
In-Reply-To: <CA+RO+X6Lat5-AZ+BoHwW8xzhXuNOTjQewyNAvzOjWF_Md0x_yA@mail.gmail.com>

```
Hi there,

Just an update, I have upgraded git to the latest version (2.35.1),
and this bug still exists.

Thanks,
Zhuo

On Wed, Feb 2, 2022 at 1:50 PM Zhuo Cheng Du <zhuo@delphia.com> wrote:
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> 1. Create a brand new file, e.g. 'touch a.py'
> 2. Add it to worktree with 'git add a.py'
> 3. stash the file with 'git stash'
> 4. pop the stashed change with 'git stash pop', WITHOUT the --index option
>
> What did you expect to happen? (Expected behavior)
> I expect the file 'a.py' to be in unstaged area since I did not pass
> the '--index' option to 'git stash pop'
>
> What happened instead? (Actual behavior)
> The file is found in staged are are after 'git stash pop', potentially
> causing merge-conflict in certain scenarios
>
> What's different between what you expected and what actually happened?
> I want the file to be found in unstaged area. The 'git stash
> push'/'git stash pop' combo works as expected if the file is already
> added to worktree prior to this maneuver. I think the behavior should
> be consistent for brand new files as well.
>
> 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.31.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Darwin 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58
> PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64
> compiler info: clang: 12.0.0 (clang-1200.0.32.29)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /bin/zsh
>
>
> [Enabled Hooks]

```