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

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> 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" :-/