From: D. Ben Knoble Date: Wed, 24 Sep 2025 18:13:11 GMT Subject: Re: Bug report: Untracked file lost from git stash Message-ID: In-Reply-To: On Wed, Sep 24, 2025 at 11:33 AM Hosam Aly wrote: > > Hello, > > Thank you for filling out a Git bug report! > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? (Steps to reproduce your issue) > I have a file in one directory. I made many changes _and_ moved it to > a different directory, but that caused git to lose track of the > renaming due to a low similarity index. As such, I decided to do it in > two steps and used `git stash -u` to shelve my changes. Following > that, I moved the file and then tried to unstash it, assuming that the > worst that could happen would be a conflict that I would easily solve. I touch on a few helpful pieces below, but one thing I can't puzzle out: what is the "echo code3 >d2/f" representing below in the story above? (I don't think it ends up mattering for the case of the stash conflict though.) > git init . > mkdir d1 d2 > echo code1 > d1/f > git add d1/f > git commit -m 'Add file in d1' > mv d1/f d2/ > echo code2 > d2/f > git stash -u > git stash show --stat At this stage, "git stash show" is not very helpful: show [-u|--include-untracked|--only-untracked] [] [] Show the changes recorded in the stash entry as a diff between the stashed contents and the commit back when the stash entry was first created. (At least, not without "-u"): # git stash show -u d1/f | 1 - d2/f | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) On the other hand, we can do "git log --oneline --graph stash" to see that stash^3 contains a new root commit with the untracked files. So > git mv d1/f d2/ > git commit -m 'Move file to d2' > echo code3 > d2/f > git stash pop here, "git restore -SW -s stash^3 d2/f" might be what you want? For the record, the error message I get is CONFLICT (rename/delete): d1/f renamed to d2/f in Updated upstream, but deleted in Stashed changes. d2/f already exists, no checkout error: could not restore untracked files from stash On branch main Unmerged paths: (use "git restore --staged ..." to unstage) (use "git add/rm ..." as appropriate to mark resolution) deleted by them: d2/f no changes added to commit (use "git add" and/or "git commit -a") Your stash currently has 1 entry The stash entry is kept in case you need it again. And then # g ls-files --stage 100644 47f43aef120505c79eafd2b1bd55e4cb78977f98 1 d2/f 100644 47f43aef120505c79eafd2b1bd55e4cb78977f98 2 d2/f That is the code1 blob. The working tree still has code3. It _would_ be nice to perhaps see a conflict with the code2 blob? > > What did you expect to happen? (Expected behavior) > * `git stash show` should show a file that was deleted and another > that is untracked and has different contents. > * `git stash pop` should apply the changes, potentially with the > conflict markers. > > What happened instead? (Actual behavior) > * The stash shows the deleted file but not the untracked one! > ``` > d1/f | 1 - > 1 file changed, 1 deletion(-) > ``` > * `git stash pop` says it's unable to restore the untracked file. > > What's different between what you expected and what actually happened? > * The stash entry doesn't show the untracked file. It should show it > (or refuse to create the stash). > * Trying `git checkout 'stash@{0}' -- d2/f` says it doesn't know about the file. The merge result in stash^{tree} doesn't have the untracked file, but it does exist in stash^3 as explained above. Yet another way to recover is "git stash branch ", which should never fail from a clean working tree. -- D. Ben Knoble