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.
Best Wishes
Phillip
First, Git is told to track a file called README/README
Then the file is removed, without telling Git.
And a new, unkown file appers on disk (which collides with the name
of the directory)
Using this sequence could have told Git, what is going on:
git mv README/README README2
rmdir README
git mv README2 README
(a temporary branch may be checked out, with the option
to merge-squash the final result)
An other alternative could be to tell `git stash` to care
about untracked file(s):
git stash -u
git stash pop
Which will refuse to apply the stash.
A third alternative could be to keep the file inside an
editor, to have the content still available.
However, it would/could be nice, if files are not simply deleted,
but saved into a "lost+found" folder, or a wastebasket kind of thing.
But which files ?
Those that are untracked ?
They may be important (local config files, passwords, help scripts, ...)
or not (.o files from a C compiler).
In some older discussions they had been named "precious" files.
But, as far as I remember, there was no easy solution.
In that sense I don't have a better answer.
Others may have.
Thanks for reporting, it make me read [1] and come to the conclusion
that it is sometimes safer to checkout out a temporary branch, commit
everything and clean up later, rather than relying too much on
`git stash`
<https://stackoverflow.com/questions/835501/how-do-you-stash-an-untracked-file>
What's different between what you expected and what actually happened?
The file doesn't exist anymore and I can't recover it.
Anything else you want to add:
This is just a reproducible example.
