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

From: Johannes Sixt <j6t@kdbg.org>
Date: Dec 11, 2025, 12:22 UTC
Message-ID: <d318c46c-fbc3-4e47-8c3f-165ca9a26225@kdbg.org>
In-Reply-To: <0lbeTWjDGq8hINMi-lj65HLgAIlUNZe_tzANStd9xxHQqAyZaEnaA0yPzVeY_VcReQIKNjY7eBEUGwMGvlbZ-0W0QZpux22cIHnosa0eX_k=@proton.me>

Am 11.12.25 um 12:53 schrieb Koutsouflakis Stefanos:

Show 15 quoted lines

> On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano <gitster@pobox.com> wrote:
>> The thinking has always been "'--hard' means what it says!  HARD
>> removes things harder than other modes---there is [no] need to add
>> '--force' to it".
> 
> I agree that "--hard" conveys serious intent. But I would argue
> there is a meaningful difference between "lose your uncommitted
> changes" and "lose your entire project".
> 
> To be clear, I'm addressing a very narrow scenario:
> the user has run init on an existing codebase, staged files
> with git add, but has not yet made a first commit. Running
> reset --hard at this point destroys the entire project
> with no realistic recovery path. This is almost certainly
> never intentional.

I would argue that bad "tutorials" and "recipes" are to blame. I have seen far too many that casually suggest `git reset --hard` without warning and in an easy to copy-and-paste format.

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

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

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?

-- Hannes