Re: [PATCH v2] you_still_use_that(): reword the instructions

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Aug 27, 2026, 06:49 UTC
Message-ID: <cd741511-b457-4464-aab0-56d8554bf763@app.fastmail.com>
In-Reply-To: <xmqqjypchixe.fsf@gitster.g>

On Wed, Aug 26, 2026, at 19:48, Junio C Hamano wrote:

Show 8 quoted lines

> The message is overly long and may mislead readers into thinking
> there is recourse other than adopting the new workflow.  Clarify
> that the message is there merely to help them find a replacement
> workflow, and is not offering to reconsider a decision that has
> already taken effect.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---

From the responses on the thread there was one action point that was agreed on and that is changed in this version. See the range diff at the end of this message.[1]

Spotting the changes is harder than it needs to be when there are no inter-version comments, range diff, or interdiff (any of them).

Show 14 quoted lines

>  usage.c | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git c/usage.c w/usage.c
> index 3f0118ab2a..365c0bcb90 100644
> --- c/usage.c
> +++ w/usage.c
> @@ -386,21 +386,19 @@ NORETURN void you_still_use_that(const char
> *command_name, const char *hint)
>  				 STRBUF_ENCODE_SLASH);
>
>  	fprintf(stderr,
> -		_("'%s' is nominated for removal.\n"), command_name);
> +		_("'%s' will be removed soon.\n"), command_name);

I was thinking that maybe the final bullet point could say something like

     ... and don’t send a message voting for it to come back because the
     decision has already been made

But it *could* be mentioned here instead. “The decision is final ...”

I bring this up because some replies have come in where they demonstrate that they know what to do about it. But instead of doing it they vote for the decision to be undone.[2]

    Kernel audio driver maintainer, here. The first thing I want to know
    about a branch is "whatchanged" - it tells me exactly what I want to
    know with no distractions. So I was horrified when I saw the removal
    nomination message.  Please reconsider - while git log can do it, I
    don't use git log... at all. I'd just have to add another alias that
    would be another thing to constantly collide with while using docker
    build chains with different (but usually older) versions of git.

(Although this was before you could alias deprecated commands but still.)

Honestly, it seems that some people would rather vote/lobby for the continued maintenance of git-whatchanged(1) [3] rather than execute one config change. That is just my general impression.

And I also bring this up because the commit message says:

     and [the message] is not offering to reconsider a decision that has
     already taken effect.

🔗 2: https://lore.kernel.org/git/BL3P221MB0449288C8B0FA448A227FD48833AA@BL3P221MB0449.NAMP221.PROD.OUTLOOK.COM/

† 3: This message is for the deprecated command git-pack-redundant(1)
     too but there hasn’t been any messages about wanting to get it back
     in the last year or so.

Show 23 quoted lines

>
>  	if (hint)
>  		fputs(hint, stderr);
>
>  	fprintf(stderr,
> -		_("If you still use this command, here's what you can do:\n"
> +		_("If you need a replacement:\n"
>  		  "\n"
> -		  "- read https://git-scm.com/docs/BreakingChanges.html\n"
> -		  "- check if anyone has discussed this on the mailing\n"
> -		  "  list and if they came up with something that can\n"
> -		  "  help you: https://lore.kernel.org/git/?q=%s\n"
> -		  "- send an email to <git@vger.kernel.org> to let us\n"
> -		  "  know that you still use this command and were unable\n"
> -		  "  to determine a suitable replacement\n"
> +		  "- Read https://git-scm.com/docs/BreakingChanges.html.\n\n"
> +		  "- Check what others on the mailing suggest as a replacement:\n"
> +		  "  https://lore.kernel.org/git/?q=%s\n\n"
> +		  "- Send an email to <git@vger.kernel.org> asking for help, only if\n"
> +		  "  suggestions by others do not work for you.\n"
>  		  "\n"),
>  		percent_encoded.buf);
>  	strbuf_release(&percent_encoded);

The rest looks good.

What I like the most about this patch/change is that it is more assertive and less wordy, e.g. just “If you need a replacement” not a long ceremonial sentence “If you still use this command, ...”.

[1]:

1:  fd53eb2ca3a ! 1:  dca3205b1f6 you_still_use_that(): reword the instructions
    @@ Commit message

         The message is overly long and may mislead readers into thinking
         there is recourse other than adopting the new workflow.  Clarify
    -    that it merely helps them find a replacement, rather than offering
    -    to reconsider a decision that has already taken effect.
    +    that the message is there merely to help them find a replacement
    +    workflow, and is not offering to reconsider a decision that has
    +    already taken effect.

         Signed-off-by: Junio C Hamano <gitster@pobox.com>

      ## usage.c ##
     @@ usage.c: NORETURN void you_still_use_that(const char *command_name, const char *hint)
    + 				 STRBUF_ENCODE_SLASH);
    +
    + 	fprintf(stderr,
    +-		_("'%s' is nominated for removal.\n"), command_name);
    ++		_("'%s' will be removed soon.\n"), command_name);
    +
    + 	if (hint)
      		fputs(hint, stderr);

      	fprintf(stderr,