On Sun, Jul 23, 2023 at 11:01:29AM +0100, Phillip Wood wrote: > On 22/07/2023 22:44, Torsten Bögershausen wrote: > > On Fri, Jul 21, 2023 at 07:31:53PM +0200, Till Friebe wrote: > > > 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) > > > ``` > > > git init > > > mkdir README > > > touch README/README > > > git add . > > > git commit -m "Init project" > > > echo "Test" > README/README > > > mv README/README README2 > > > rmdir README > > > mv README2 README > > > git stash > > > git stash pop > > > ``` > > > > > > What did you expect to happen? (Expected behavior) > > > I expected that after the `git stash pop` the README file would be back. > > > > > > What happened instead? (Actual behavior) > > > This README with "Test" file was deleted and I lost 5 hours of work. > > > > That is always sad to hear, when work is lost. > > Indeed it is. Thanks Till for providing an easy reproducer. > > > However, I personally wonder if this is a bug or not. > > I think whenever git overwrites an untracked file without the user passing > some option indicating that they want to do so it is a bug. OK, agreed after reading the next sentence. > For example "git > checkout" refuses to overwrite untracked files by default. Sadly this seems > to be a known bug in do_push_stash() where we are using "git reset --hard" > to remove the stashed changes from the working copy. This was documented in > 94b7f1563a (Comment important codepaths regarding nuking untracked > files/dirs, 2021-09-27). The stash implementation does a lot of necessary > forking of subprocesses, in this case I think it would be better to call > unpack_trees() directly with UNPACK_RESET_PROTECT_UNTRACKED. Thanks for the fast response. This is not an area of Git, where I have much understanding of the code. But is seems as if pop_stash() in builtin/stash.c (and the called functions) seems to be the problem here ?
