From: Junio C Hamano <gitster@pobox.com>
To: Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me>
Cc: Johannes Sixt <j6t@kdbg.org>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [RFC] reset --hard: warn before discarding staged content with no commit history
Date: Mon, 15 Dec 2025 08:27:12 +0900 [thread overview]
Message-ID: <xmqqwm2o8x0v.fsf@gitster.g> (raw)
In-Reply-To: <Ai2bA2Zt8bsexgQEIKg1vK7-SNNhTlsmmFp_gOJp8IKX9dJME7UC97EtqRhAUfD00sFmqRdHg9xgGW82rikrLIDUIswrUPr3RKm-LQgGuNY=@proton.me> (Koutsouflakis Stefanos's message of "Sun, 14 Dec 2025 13:29:54 +0000")
Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me> writes:
> 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?
next prev parent reply other threads:[~2025-12-14 23:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 15:01 [RFC] reset --hard: warn before discarding staged content with no commit history Koutsouflakis Stefanos
2025-12-11 3:24 ` Junio C Hamano
2025-12-11 3:59 ` Eric Sunshine
2025-12-11 5:25 ` Junio C Hamano
2025-12-11 11:53 ` Koutsouflakis Stefanos
2025-12-11 12:22 ` Johannes Sixt
2025-12-11 16:33 ` Koutsouflakis Stefanos
2025-12-12 3:24 ` Junio C Hamano
2025-12-14 13:29 ` Koutsouflakis Stefanos
2025-12-14 13:45 ` Štefan Balog
2025-12-14 23:27 ` Junio C Hamano [this message]
2025-12-15 7:22 ` Koutsouflakis Stefanos
2025-12-12 22:14 ` D. Ben Knoble
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwm2o8x0v.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=koutsouflakis.stefanos@proton.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).