From: Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me>
Date: Mon, 15 Dec 2025 07:22:54 GMT
Subject: Re: [RFC] reset --hard: warn before discarding staged content with no commit history
Message-ID: <inl6W-7dpE2-dCPugnjAM-X01zhKAp5niQNigtqe5EVKEMEy1KEPFegzDC1zjpm7etuqAoVjg1gUd8_5vFO90LhaGmzLc3HJTE4MREXtzH8=@proton.me>
In-Reply-To: <xmqqwm2o8x0v.fsf@gitster.g>

On Monday, December 15th, 2025 at 01:27, Junio C Hamano <gitster@pobox.com> wrote:

> 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?

That actually makes sense. For tools as versatile as Git, it is
sometimes hard to see the bigger picture and the different ways 
of people using it. 
I'll drop the proposal, and thanks everyone for your time.

-- Stefanos