Ok I have been bitten by this issue twice. :(
`git reset --hard` will reset modifications in the working directory
(of course). But if I remove a file, add a directory with the same
name, `git reset --hard` will erase that whole directory.
Specifically the following steps:
```
touch file
git add file
git commit -m "add file"
# now the HEAD is constructed
rm file
mkdir file
touch file/a
# now here is the issue
git reset --hard # this will remove the directory and all its files
```
I guess this has to do with Git not tracking "changing a file to a
directory", especially because one is a blob and another is a tree.
In case of `git reset --hard`, people would expect reverting
modifications, bringing up removed files, but not removing a whole
directory with the same name. Especially if the directory is already
populated. Then the whole thing is gone.
I think it would better if Git could output a warning and abort, like
in case of checkout ("Updating the following ... would lose ...").
But honestly I usually take `git reset --hard` seriously and will
double check before invocation. What actually bit me was `git stash`.
It will call `git reset --hard -q` after saving the working directory.
But in the case I just described, since the new directory is not
tracked, it will not be saved and will be erased. `git stash` usually
gives me the mental model of "saving stuff in working directory", but
not like in this case where it also deletes stuff in working
directory.
