Re: Lost files after git stash && git stash pop

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

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