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

Patrick Steinhardt [off-list ref] writes:

On Thu, May 01, 2025 at 03:59:56PM -0700, Junio C Hamano wrote:

quoted

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.