Re: Bug report: Untracked file lost from git stash

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Sep 24, 2025, 18:13 UTC
Message-ID: <CALnO6CCfwdKcqxFSvX68WDvzceYeo0ougz4337ejChbPB9aGEg@mail.gmail.com>
In-Reply-To: <CAJA-u1rnzef53+eW_mbwd_40q+-vt747Q_dP3PG_HKt1yXcmXQ@mail.gmail.com>

On Wed, Sep 24, 2025 at 11:33 AM Hosam Aly <hosamaly6@gmail.com> wrote:

Show 13 quoted lines

>
> 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.)

Show 9 quoted lines

> 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?

Show 19 quoted lines

>
> 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