Re: [PATCH v2 0/2] Nominating "whatchanged" for removal

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2025, 16:46 UTC
Message-ID: <xmqqselnufit.fsf@gitster.g>
In-Reply-To: <aBSLejDoqomUO3xE@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 8 quoted lines

> On Thu, May 01, 2025 at 03:59:56PM -0700, Junio C Hamano wrote:
>> This does not go far enough to touch the "Git 3.0 removal" list in
>> Documentation/BreakingChanges.adoc, but is a preparatory step
>> necessary if we ever wanted to do so in the future.
>
> I'm a little confused. These patches very much feel like starting the
> deprecation process for git-whatchanged(1), so why wouldn't we at the
> same time list it as an upcoming breaking change?

Ah, yes, I was overly eager in the documentation change.

To make an analogy of what happened to pack-redundant, this corresponds to c3b58472 (pack-redundant: gauge the usage before proposing its removal, 2020-08-25) plus 4406522b (pack-redundant: escalate deprecation warning to an error, 2023-03-23) rolled into one. We are gauging the impact of the removal by inconveniencing existing users a big way, with a tiny escape hatch to make them feel the pain, so that we can hear their scream better.

We are not there yet to announce the decision to deprecate, like fcf31daa (pack-redundant: document deprecation, 2023-03-28) did, to those who do not even use the command. I think it may make sense to hold that WARNING part of the change, leaving it to a future step that touches the BreakingChanges document.

> Or is the intent
> rather to figure out whether anybody is still using this command so that
> we can then deprecate it after a couple releases if we haven't heard
> back from anybody?

Yes, exactly.

Thanks.