From: Hosam Aly Date: Thu, 25 Sep 2025 20:22:40 GMT Subject: Re: Bug report: Untracked file lost from git stash Message-ID: In-Reply-To: One learns everyday, and today is definitely a good one. Thanks a lot! It was a red herring but I do have a feature suggestion at the end of this message. I had found `git stash show` easy to use that I never thought about reading its docs. I apologise for the false alarm. I was surprised to learn that `git stash` has an option to show untracked files. I find this unintuitive because it's the opposite of the default behaviour of `git status`! I'll configure `stash.showIncludeUntracked` to get them to behave similarly. Thanks very much for pointing it out. I learned today how `git stash branch` can be a lifesaver. Much appreciated! As for "echo code3 >d2/f", I had written it in an incorrect order. It should've been after the move and before the commit. The actual scenario was that I was working with a Java file that I moved to a different package, which involved changing the package declaration at the top of the file. Feature request: I wish that the maintainers would consider changing the default value of `stash.showIncludeUntracked` to true. If something is stashed and the user asks about it, they should be told about it without hiding anything. Consider the case where all the stashed files are untracked; `git stash show` currently shows nothing, which is very confusing. Thank you very much, Hosam Aly On Wed, 24 Sept 2025 at 21:13, D. Ben Knoble wrote: > > 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