Re: [RFC] reset --hard: warn before discarding staged content with no commit history

Johannes Sixt [off-list ref] writes:

Wouldn't the following slightly different scenario warrant a similar
safety net:

   git commit --allow-empty -m "Initial commit"
   git add .
   git reset --hard

Yes, I think everybody has lost new files not in an empty tree but
more often (1) create a new file and add it, (2) make modifications
to existing files, (3) compile, test, debug, get frustrated, and
finally (4) decide to give up and start from scratch, with "reset
--hard".  When (1) is much larger than (2), the sense of loss is
big.

That said, I have some sympathy for the case. Would it be palatable to
have `git reset --hard` refuse to do anything if the destination tree is
empty?

I doubt that special casing an empty tree would fly well.

It is tempting to special case removals, but then I sill am not sure
it is good to do nothing and fail the command after determining that
the operation is a common pitfall of removing a new file that
appears nowhere else.  Unconditionally going interactive is a no-no.

And I do not have any better ideas.  Other than just failing, that is.
But that leads to nonsense combination "--hard --force", just as
idiotic combination as "rm -f -i" :-/