{"thread":{"id":"64198","subject":"Bug report: Untracked file lost from git stash","startedAt":"2025-09-24T15:30:34Z","lastAt":"2025-09-25T21:06:41Z","messageCount":4,"participants":["Hosam Aly","D. Ben Knoble","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"527226","messageId":"CAJA-u1rnzef53+eW_mbwd_40q+-vt747Q_dP3PG_HKt1yXcmXQ@mail.gmail.com","threadId":"64198","inReplyTo":null,"subject":"Bug report: Untracked file lost from git stash","fromName":"Hosam Aly","fromEmail":"hosamaly6@gmail.com","sentAt":"2025-09-24T15:29:57Z","receivedAt":"2025-09-24T15:30:34Z","isPatch":false,"sender":{"key":"hosamaly6@gmail.com","avatar":"https://gravatar.com/avatar/0e26156a8f5c39fd6e63da9eaa92d0b5a098ca6eac70c594f5fc39d270b46b6e?d=mp&s=160"},"body":"Hello,\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\nI have a file in one directory. I made many changes _and_ moved it to\na different directory, but that caused git to lose track of the\nrenaming due to a low similarity index. As such, I decided to do it in\ntwo steps and used `git stash -u` to shelve my changes. Following\nthat, I moved the file and then tried to unstash it, assuming that the\nworst that could happen would be a conflict that I would easily solve.\n```\ngit init .\nmkdir d1 d2\necho code1 > d1/f\ngit add d1/f\ngit commit -m 'Add file in d1'\nmv d1/f d2/\necho code2 > d2/f\ngit stash -u\ngit stash show --stat\n\ngit mv d1/f d2/\ngit commit -m 'Move file to d2'\necho code3 > d2/f\ngit stash pop\n```\n\nWhat did you expect to happen? (Expected behavior)\n* `git stash show` should show a file that was deleted and another\nthat is untracked and has different contents.\n* `git stash pop` should apply the changes, potentially with the\nconflict markers.\n\nWhat happened instead? (Actual behavior)\n* The stash shows the deleted file but not the untracked one!\n  ```\n   d1/f | 1 -\n   1 file changed, 1 deletion(-)\n  ```\n* `git stash pop` says it's unable to restore the untracked file.\n\nWhat's different between what you expected and what actually happened?\n* The stash entry doesn't show the untracked file. It should show it\n(or refuse to create the stash).\n* Trying `git checkout 'stash@{0}' -- d2/f` says it doesn't know about the file.\n\nAnything else you want to add:\nI seem to have lost the changes I made (symbolized by code2 above).\nI wasn't able to restore them using any of the git commands that I know.\nI'm no expert but I'm the best in my company at using Git, and yet I wasn't\nable to restore code2 using any git commands.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.51.0\ncpu: arm64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nlibcurl: 8.7.1\nzlib: 1.2.12\nSHA-1: SHA1_DC\nSHA-256: SHA256_BLK\ndefault-ref-format: files\ndefault-hash: sha1\nuname: Darwin 24.6.0 Darwin Kernel Version 24.6.0: Mon Aug 11 21:15:09\nPDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6041 arm64\ncompiler info: clang: 17.0.0 (clang-1700.0.13.3)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\n"},{"id":"527244","messageId":"CALnO6CCfwdKcqxFSvX68WDvzceYeo0ougz4337ejChbPB9aGEg@mail.gmail.com","threadId":"64198","inReplyTo":"CAJA-u1rnzef53+eW_mbwd_40q+-vt747Q_dP3PG_HKt1yXcmXQ@mail.gmail.com","subject":"Re: Bug report: Untracked file lost from git stash","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-24T18:13:11Z","receivedAt":"2025-09-24T18:13:24Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Wed, Sep 24, 2025 at 11:33 AM Hosam Aly <hosamaly6@gmail.com> wrote:\n>\n> Hello,\n>\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> I have a file in one directory. I made many changes _and_ moved it to\n> a different directory, but that caused git to lose track of the\n> renaming due to a low similarity index. As such, I decided to do it in\n> two steps and used `git stash -u` to shelve my changes. Following\n> that, I moved the file and then tried to unstash it, assuming that the\n> worst that could happen would be a conflict that I would easily solve.\n\nI touch on a few helpful pieces below, but one thing I can't puzzle\nout: what is the \"echo code3 >d2/f\" representing below in the story\nabove? (I don't think it ends up mattering for the case of the stash\nconflict though.)\n\n> git init .\n> mkdir d1 d2\n> echo code1 > d1/f\n> git add d1/f\n> git commit -m 'Add file in d1'\n> mv d1/f d2/\n> echo code2 > d2/f\n> git stash -u\n> git stash show --stat\n\nAt this stage, \"git stash show\" is not very helpful:\n\nshow [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]\n           Show the changes recorded in the stash entry as a diff between the\n           stashed contents and the commit back when the stash entry was first\n           created.\n\n(At least, not without \"-u\"):\n\n    # git stash show -u\n     d1/f | 1 -\n     d2/f | 1 +\n     2 files changed, 1 insertion(+), 1 deletion(-)\n\nOn the other hand, we can do \"git log --oneline --graph stash\" to see\nthat stash^3 contains a new root commit with the untracked files.\n\nSo\n\n> git mv d1/f d2/\n> git commit -m 'Move file to d2'\n> echo code3 > d2/f\n> git stash pop\n\nhere, \"git restore -SW -s stash^3 d2/f\" might be what you want?\n\nFor the record, the error message I get is\n\nCONFLICT (rename/delete): d1/f renamed to d2/f in Updated upstream,\nbut deleted in Stashed changes.\nd2/f already exists, no checkout\nerror: could not restore untracked files from stash\nOn branch main\nUnmerged paths:\n  (use \"git restore --staged <file>...\" to unstage)\n  (use \"git add/rm <file>...\" as appropriate to mark resolution)\ndeleted by them: d2/f\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nYour stash currently has 1 entry\nThe stash entry is kept in case you need it again.\n\nAnd then\n\n    # g ls-files --stage\n    100644 47f43aef120505c79eafd2b1bd55e4cb78977f98 1 d2/f\n    100644 47f43aef120505c79eafd2b1bd55e4cb78977f98 2 d2/f\n\nThat is the code1 blob. The working tree still has code3. It _would_\nbe nice to perhaps see a conflict with the code2 blob?\n\n>\n> What did you expect to happen? (Expected behavior)\n> * `git stash show` should show a file that was deleted and another\n> that is untracked and has different contents.\n> * `git stash pop` should apply the changes, potentially with the\n> conflict markers.\n>\n> What happened instead? (Actual behavior)\n> * The stash shows the deleted file but not the untracked one!\n>   ```\n>    d1/f | 1 -\n>    1 file changed, 1 deletion(-)\n>   ```\n> * `git stash pop` says it's unable to restore the untracked file.\n>\n> What's different between what you expected and what actually happened?\n> * The stash entry doesn't show the untracked file. It should show it\n> (or refuse to create the stash).\n> * Trying `git checkout 'stash@{0}' -- d2/f` says it doesn't know about the file.\n\nThe merge result in stash^{tree} doesn't have the untracked file, but\nit does exist in stash^3 as explained above.\n\nYet another way to recover is \"git stash branch <branch>\", which\nshould never fail from a clean working tree.\n\n-- \nD. Ben Knoble\n"},{"id":"527354","messageId":"CAJA-u1oORK9b2=mg-s_n6-Jn3VBhe6sqrWg8VN0-MdEOjZGcwg@mail.gmail.com","threadId":"64198","inReplyTo":"CALnO6CCfwdKcqxFSvX68WDvzceYeo0ougz4337ejChbPB9aGEg@mail.gmail.com","subject":"Re: Bug report: Untracked file lost from git stash","fromName":"Hosam Aly","fromEmail":"hosamaly6@gmail.com","sentAt":"2025-09-25T20:22:40Z","receivedAt":"2025-09-25T20:23:18Z","isPatch":false,"sender":{"key":"hosamaly6@gmail.com","avatar":"https://gravatar.com/avatar/0e26156a8f5c39fd6e63da9eaa92d0b5a098ca6eac70c594f5fc39d270b46b6e?d=mp&s=160"},"body":"One learns everyday, and today is definitely a good one. Thanks a lot!\nIt was a red herring but I do have a feature suggestion at the end of\nthis message.\n\nI had found `git stash show` easy to use that I never thought about\nreading its docs. I apologise for the false alarm.\n\nI was surprised to learn that `git stash` has an option to show\nuntracked files. I find this unintuitive because it's the opposite of\nthe default behaviour of `git status`! I'll configure\n`stash.showIncludeUntracked` to get them to behave similarly. Thanks\nvery much for pointing it out.\n\nI learned today how `git stash branch` can be a lifesaver. Much appreciated!\n\nAs for \"echo code3 >d2/f\", I had written it in an incorrect order. It\nshould've been after the move and before the commit. The actual\nscenario was that I was working with a Java file that I moved to a\ndifferent package, which involved changing the package declaration at\nthe top of the file.\n\nFeature request: I wish that the maintainers would consider changing\nthe default value of `stash.showIncludeUntracked` to true. If\nsomething is stashed and the user asks about it, they should be told\nabout it without hiding anything. Consider the case where all the\nstashed files are untracked; `git stash show` currently shows nothing,\nwhich is very confusing.\n\n\nThank you very much,\nHosam Aly\n\nOn Wed, 24 Sept 2025 at 21:13, D. Ben Knoble <ben.knoble@gmail.com> wrote:\n>\n> On Wed, Sep 24, 2025 at 11:33 AM Hosam Aly <hosamaly6@gmail.com> wrote:\n> >\n> > Hello,\n> >\n> > Thank you for filling out a Git bug report!\n> > Please answer the following questions to help us understand your issue.\n> >\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> > I have a file in one directory. I made many changes _and_ moved it to\n> > a different directory, but that caused git to lose track of the\n> > renaming due to a low similarity index. As such, I decided to do it in\n> > two steps and used `git stash -u` to shelve my changes. Following\n> > that, I moved the file and then tried to unstash it, assuming that the\n> > worst that could happen would be a conflict that I would easily solve.\n>\n> I touch on a few helpful pieces below, but one thing I can't puzzle\n> out: what is the \"echo code3 >d2/f\" representing below in the story\n> above? (I don't think it ends up mattering for the case of the stash\n> conflict though.)\n>\n> > git init .\n> > mkdir d1 d2\n> > echo code1 > d1/f\n> > git add d1/f\n> > git commit -m 'Add file in d1'\n> > mv d1/f d2/\n> > echo code2 > d2/f\n> > git stash -u\n> > git stash show --stat\n>\n> At this stage, \"git stash show\" is not very helpful:\n>\n> show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]\n>            Show the changes recorded in the stash entry as a diff between the\n>            stashed contents and the commit back when the stash entry was first\n>            created.\n>\n> (At least, not without \"-u\"):\n>\n>     # git stash show -u\n>      d1/f | 1 -\n>      d2/f | 1 +\n>      2 files changed, 1 insertion(+), 1 deletion(-)\n>\n> On the other hand, we can do \"git log --oneline --graph stash\" to see\n> that stash^3 contains a new root commit with the untracked files.\n>\n> So\n>\n> > git mv d1/f d2/\n> > git commit -m 'Move file to d2'\n> > echo code3 > d2/f\n> > git stash pop\n>\n> here, \"git restore -SW -s stash^3 d2/f\" might be what you want?\n>\n> For the record, the error message I get is\n>\n> CONFLICT (rename/delete): d1/f renamed to d2/f in Updated upstream,\n> but deleted in Stashed changes.\n> d2/f already exists, no checkout\n> error: could not restore untracked files from stash\n> On branch main\n> Unmerged paths:\n>   (use \"git restore --staged <file>...\" to unstage)\n>   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n> deleted by them: d2/f\n>\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> Your stash currently has 1 entry\n> The stash entry is kept in case you need it again.\n>\n> And then\n>\n>     # g ls-files --stage\n>     100644 47f43aef120505c79eafd2b1bd55e4cb78977f98 1 d2/f\n>     100644 47f43aef120505c79eafd2b1bd55e4cb78977f98 2 d2/f\n>\n> That is the code1 blob. The working tree still has code3. It _would_\n> be nice to perhaps see a conflict with the code2 blob?\n>\n> >\n> > What did you expect to happen? (Expected behavior)\n> > * `git stash show` should show a file that was deleted and another\n> > that is untracked and has different contents.\n> > * `git stash pop` should apply the changes, potentially with the\n> > conflict markers.\n> >\n> > What happened instead? (Actual behavior)\n> > * The stash shows the deleted file but not the untracked one!\n> >   ```\n> >    d1/f | 1 -\n> >    1 file changed, 1 deletion(-)\n> >   ```\n> > * `git stash pop` says it's unable to restore the untracked file.\n> >\n> > What's different between what you expected and what actually happened?\n> > * The stash entry doesn't show the untracked file. It should show it\n> > (or refuse to create the stash).\n> > * Trying `git checkout 'stash@{0}' -- d2/f` says it doesn't know about the file.\n>\n> The merge result in stash^{tree} doesn't have the untracked file, but\n> it does exist in stash^3 as explained above.\n>\n> Yet another way to recover is \"git stash branch <branch>\", which\n> should never fail from a clean working tree.\n>\n> --\n> D. Ben Knoble\n"},{"id":"527356","messageId":"xmqq4isqfdi9.fsf@gitster.g","threadId":"64198","inReplyTo":"CAJA-u1oORK9b2=mg-s_n6-Jn3VBhe6sqrWg8VN0-MdEOjZGcwg@mail.gmail.com","subject":"Re: Bug report: Untracked file lost from git stash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-25T21:06:38Z","receivedAt":"2025-09-25T21:06:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hosam Aly <hosamaly6@gmail.com> writes:\n\n> Feature request: I wish that the maintainers would consider changing\n> the default value of `stash.showIncludeUntracked` to true. If\n> something is stashed and the user asks about it, they should be told\n> about it without hiding anything. Consider the case where all the\n> stashed files are untracked; `git stash show` currently shows nothing,\n> which is very confusing.\n\nDo we include untracked paths in the stash by default without\nconfiguration and/or command line option?  If we do, then such a\nchange will affect so many folks that it would be possible to do so\nonly at a large version boundary, like Git 3.0.\n\nBut untracked paths are not recorded by default, and a stash entry\nthat records the untracked ones is a sign enough that the user cares\nabout these untracked ones when the stash entry was created.\n\nEven though I do dislike any suggestion to change existing behaviour\nestablished more than a few years, I would be more sympathetic than\nusual to a wish for such a change in the default.  In other words, I\ntend to agree that the default should show untracked if recorded.  I\nam actually tempted to argue that the presence of the configuration\nvariable stash.showIncludeUntracked and the \"--include-untracked\"\ncommand line option is a bug ;-) but I won't.\n\nThanks.\n\n\n\n\n"}]}