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
