On Tue, Aug 25, 2020 at 11:05:09AM -0700, Junio C Hamano wrote:
> Subject: [RFC] pack-redundant: gauge the usage before proposing its removal
>
> The subcommand is unusably slow and the reason why nobody reports it
> as a performance bug is suspected to be the absense of users. Let's
> disable the normal use of command by making it error out with a big
> message that asks the user to tell us that they still care about the
> command, with an escape hatch to override it with a command line
> option.
I like this direction. And I'm tempted to say it's OK to go straight
here given how generally useless the command is. But it feels like a big
jump for the initial change. While we give the user an easy escape
hatch, it might still break their scripts.
A more gentle transition would I guess be:
1. Mention deprecation in release notes (hah, as if anybody reads
them).
2. Issue a warning but continue to behave as normal. That might break
scripts that care a lot about stderr, but otherwise is harmless. No
clue if anybody would actually see the message or not.
3. Flip warning to error, as your patch does.
4. Removal.
I'd guess we could do 1+2 in one release, then 3 a release or two later,
and then finally 4. I dunno. That's more tedious and I'll be surprised
if we get any bites, but maybe we ought to do it out of principle.
-Peff
