Re: Bug report: Untracked file lost from git stash

From: Hosam Aly <hosamaly6@gmail.com>
Date: Sep 25, 2025, 20:22 UTC
Message-ID: <CAJA-u1oORK9b2=mg-s_n6-Jn3VBhe6sqrWg8VN0-MdEOjZGcwg@mail.gmail.com>
In-Reply-To: <CALnO6CCfwdKcqxFSvX68WDvzceYeo0ougz4337ejChbPB9aGEg@mail.gmail.com>

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 <ben.knoble@gmail.com> wrote:

Show 110 quoted lines

>
> On Wed, Sep 24, 2025 at 11:33 AM Hosam Aly <hosamaly6@gmail.com> 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] [<diff-options>] [<stash>]
>            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 <file>..." to unstage)
>   (use "git add/rm <file>..." 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 <branch>", which
> should never fail from a clean working tree.
>
> --
> D. Ben Knoble