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

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Jan 4, 2022, 21:05 UTC
Message-ID: <004201d801ae$e238f330$a6aad990$@nexbridge.com>
In-Reply-To: <CACEm96jjWALB=iPiBNr0P5HrX9Oo3bXm_k1PpxsHm4Ns9M-vOQ@mail.gmail.com>

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