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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 14, 2025, 23:27 UTC
Message-ID: <xmqqwm2o8x0v.fsf@gitster.g>
In-Reply-To: <Ai2bA2Zt8bsexgQEIKg1vK7-SNNhTlsmmFp_gOJp8IKX9dJME7UC97EtqRhAUfD00sFmqRdHg9xgGW82rikrLIDUIswrUPr3RKm-LQgGuNY=@proton.me>

Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me> writes:

Show 6 quoted lines

> On Friday, December 12th, 2025 at 05:25, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I doubt that special casing an empty tree would fly well.
>
> I might be missing something, could you say more about 
> what makes this problematic?

Inconsistency.

Treating "newly added files" specifically is making the behaviour inconsistent with others already, but doing so only when you haven't created a commit or after doing "checkout/switch --orphan", which is essentially what special-casing an empty tree case is about, makes it even more inconsistent.

> If it is about breaking existing workflows: any script that 
> automates either of the two use-cases discussed would be relying 
> on behavior that is almost certainly unintended.

I do not think that is the reason for "special casing an empty tree would not fly well", but I have to say your view is too narow. I do rely on "reset --hard && clean -f -x" working in order to make the working tree spiffy clean, and I somehow doubt I am in the minority. And "reset --hard" MUST not fail in such a case.

> Such scripts 
> would fail, but without data loss, and give authors a clear 
> signal to fix a likely bug.

And most authors will consider the "bug" to be fixed is in the degraded behaviour of "reset --hard". that does not do what is written on the label Then what?