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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 12, 2025, 03:24 UTC
Message-ID: <xmqqzf7ocrhk.fsf@gitster.g>
In-Reply-To: <d318c46c-fbc3-4e47-8c3f-165ca9a26225@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 6 quoted lines

> 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" :-/