Git stash pop with untracked files doesn't unpack untracked if a conflict happens?

user_1067688 0
Viewed 779

This behavior feels more like a bug to me, but maybe I'm missing something.

Firstly, here is what I did:

0) `mkdir mytest && cd mytest`
1) `git init`: Created an empty git repo
2) `echo "test" >test.txt && git commit -a -m "init"`: Created 1 commit with a single file
3) `echo "test2" >test.txt && echo "test2" >test2.txt`: Made some changes in the file i committed + created a new file
4) `git stash -u`: Used stash -u to save my changes
5) `echo "test3" >test.txt && git commit -a -m "2"`: Created a second commit with a different change on the existing file in order to force a conflict
6) `git stash pop`: I git stash pop to create a conflict between the second commit and my stash from my first commit

I was expecting to have 1 file in conflict stage and the untracked file to be created in my current working directory, but when I run git status I could only find the conflict:

mytest git:(master) ✗ git status
On branch master
Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
    both modified:   test.txt

Is this expected behaviour? How can I resolve the conflict and get the untracked file of mine back?

git-stash git
2 Answers

Note that, technically, what's stored in the stash is a commit (a merge commit to be more precise).

You can view this by running :

git log --oneline --graph stash

The part with the untracked files (when you run git stash -u) is the 3rd parent of the stash commit : stash^3

If you are in a situation where using git stash apply or git stash pop doesn't work, because conflicts are triggered when restoring the tracked part of the files, you can :

  • fix the issues with that first part (e.g : fix the conflicts on test.txt),
  • use other git commands to list or extract files from the "untracked files" part of the stash :
git show --name-only stash^3
git checkout stash^3 -- that/file # warning : will overwrite the content of
                                  # 'that/file' if you have a local one

# if you have a clean index :
git checkout stash^3 -- .
git reset HEAD

# etc ...
user_860720

If the conflict resolves to one or the other you're okay, you can just resolve it then git stash pop again to get the untracked files back, but if any resolution hunk isn't identical to either parent you're going to have to do this manually: resolve the merge conflicts, then

# after resolving conflicts
index=`git write-tree`
git read-tree -u --prefix= stash^3
git read-tree $index

No, this shouldn't be normal.

user_12907310
Related