RE: Stash Apply/Pop not restoring added files when conflict occurs on restore
On January 4, 2022 2:00 PM, AJ Henderson wrote:
Show 14 quoted lines
> 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
