# Stash Apply/Pop not restoring added files when conflict occurs on restore

3 messages from 2022-01-04 to 2022-01-05. Participants: AJ Henderson, rsbecker@nexbridge.com, Eric Sunshine.
Thread: https://gitlist.dev/t/57181

## AJ Henderson, 2022-01-04 19:00

Subject: Stash Apply/Pop not restoring added files when conflict occurs on restore
Message-ID: <CACEm96jjWALB=iPiBNr0P5HrX9Oo3bXm_k1PpxsHm4Ns9M-vOQ@mail.gmail.com>
URL: https://gitlist.dev/e/CACEm96jjWALB%3DiPiBNr0P5HrX9Oo3bXm_k1PpxsHm4Ns9M-vOQ%40mail.gmail.com

```
I have had two developers have this problem 3 times.  When they are
doing a stash push with newly created files and old files, when they
go to do a stash pop, if there is no conflict, the files show up as
expected, but when there is a conflict, the modified files are
restored (and placed in a conflict state as expected), however, the
new files are not restored.

We are able to work around this issue by grabbing the files directly
out of the log for the stash head, but are unsure why this behavior
isn't working as expected.  It seems to be a new change in behavior as
we had never previously seen this issue, but have seen it 3 times now
in the last few weeks.

We are running 64 bit Windows with Git For Windows version 2.34.1.windows.1


```

## rsbecker@nexbridge.com, 2022-01-04 21:05

Subject: RE: Stash Apply/Pop not restoring added files when conflict occurs on restore
Message-ID: <004201d801ae$e238f330$a6aad990$@nexbridge.com>
URL: https://gitlist.dev/e/004201d801ae%24e238f330%24a6aad990%24%40nexbridge.com
In-Reply-To: <CACEm96jjWALB=iPiBNr0P5HrX9Oo3bXm_k1PpxsHm4Ns9M-vOQ@mail.gmail.com>

```
On January 4, 2022 2:00 PM, AJ Henderson wrote:
> I have had two developers have this problem 3 times.  When they are doing a
> stash push with newly created files and old files, when they go to do a stash
> pop, if there is no conflict, the files show up as expected, but when there is a
> conflict, the modified files are restored (and placed in a conflict state as
> expected), however, the new files are not restored.
> 
> We are able to work around this issue by grabbing the files directly out of the
> log for the stash head, but are unsure why this behavior isn't working as
> expected.  It seems to be a new change in behavior as we had never
> previously seen this issue, but have seen it 3 times now in the last few
> weeks.
> 
> We are running 64 bit Windows with Git For Windows version
> 2.34.1.windows.1

This looks like a regression from 2.33.0 to 2.34.1 in git. I can recreate the problem in 2.34.1, as follows:

$ mkdir test
$ cd test
$ git init
$ cat >a <<-EOF
Hi
EOF
$ cat >b <<-EOF
There
EOF
$ git add .
$ git commit -m "First"
$ cat >a <<-EOF
Hello
EOF
$ cat >c <<-EOF
Something
EOF
$ git stash push --include-untracked
$ cat >a <<-EOF
Conflict
EOF
$ git add a
$ git commit -m "Second"
$ git stash pop
Auto-merging a
CONFLICT (content): Merge conflict in a
The stash entry is kept in case you need it again.

* d8411cf (HEAD -> master) Second
| *   0bf6efc (refs/stash) WIP on master: c9bfeb9 First
|/|\
| | * 002560a untracked files on master: c9bfeb9 First
| * 6ad65b4 index on master: c9bfeb9 First
|/
* c9bfeb9 First

The stash contains c but has not been restored. In 2.33.0, c was restored and the conflict for a identified. In both versions, the stash is retained.
--Randall



```

## Eric Sunshine, 2022-01-05 06:15

Subject: Re: Stash Apply/Pop not restoring added files when conflict occurs on restore
Message-ID: <CAPig+cRhBg9fvAAfzQUrPKqyFKoBtx7GQoiwpyaQr0bajBvfHQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAPig%2BcRhBg9fvAAfzQUrPKqyFKoBtx7GQoiwpyaQr0bajBvfHQ%40mail.gmail.com
In-Reply-To: <CACEm96jjWALB=iPiBNr0P5HrX9Oo3bXm_k1PpxsHm4Ns9M-vOQ@mail.gmail.com>

```
On Wed, Jan 5, 2022 at 1:08 AM AJ Henderson <ahenderson@datto.com> wrote:
> I have had two developers have this problem 3 times.  When they are
> doing a stash push with newly created files and old files, when they
> go to do a stash pop, if there is no conflict, the files show up as
> expected, but when there is a conflict, the modified files are
> restored (and placed in a conflict state as expected), however, the
> new files are not restored.
>
> We are able to work around this issue by grabbing the files directly
> out of the log for the stash head, but are unsure why this behavior
> isn't working as expected.  It seems to be a new change in behavior as
> we had never previously seen this issue, but have seen it 3 times now
> in the last few weeks.

As a follow-up for anyone who comes across this thread in the future,
Elijah posted a patch[*] to fix this regression.

[*] https://lore.kernel.org/git/pull.1180.git.git.1641337498996.gitgitgadget@gmail.com/

```