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

From: Štefan Balog <stevobalog123@gmail.com>
Date: Dec 14, 2025, 13:45 UTC
Message-ID: <CAJq5WQ5+LBNR11gC+XPT6Z1ZZQZ0HLXxtZdRDoS+wpDjAy2itA@mail.gmail.com>
In-Reply-To: <Ai2bA2Zt8bsexgQEIKg1vK7-SNNhTlsmmFp_gOJp8IKX9dJME7UC97EtqRhAUfD00sFmqRdHg9xgGW82rikrLIDUIswrUPr3RKm-LQgGuNY=@proton.me>

Dôvera, spolupráca, jednota ! Jedina cesta posunu genetického kódu a vyvoja pre zlepšenie kvality života ľudí a spoločnosti v ktorej víťazí dokonalá súhra dôvery viery a nádeje v lepší svet v symbióze s kozmom.

World Rescue Organization

Dňa ne, 14. dec 2025, 14:30 Koutsouflakis Stefanos < koutsouflakis.stefanos@proton.me> napísal(a):

Show 26 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?
> 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. Such scripts
> would fail, but without data loss, and give authors a clear
> signal to fix a likely bug.
>
> > 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" :-/
>
> There might be other ways to mitigate this, e.g.:
> a) Refuse with a fatal error and hint the user
>    to remove staged content with "git rm --cached -r ."
> b) Autostash with a warning
>
> Thanks,
> Stefanos
>
>