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

[<rsbecker@nexbridge.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