From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org, "Michael Montalbo" <mmontalbo@gmail.com>,
"Elijah Newren" <newren@gmail.com>
Subject: Re: [PATCH v2] you_still_use_that(): reword the instructions
Date: Thu, 27 Aug 2026 08:49:27 +0200 [thread overview]
Message-ID: <cd741511-b457-4464-aab0-56d8554bf763@app.fastmail.com> (raw)
In-Reply-To: <xmqqjypchixe.fsf@gitster.g>
On Wed, Aug 26, 2026, at 19:48, Junio C Hamano wrote:
> 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).
> 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.
>
> 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,
next prev parent reply other threads:[~2026-08-27 6:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 14:33 [PATCH] you_still_use_that(): reword the instructions Junio C Hamano
2026-08-26 16:04 ` Michael Montalbo
2026-08-26 17:00 ` Junio C Hamano
2026-08-26 17:12 ` Michael Montalbo
2026-08-26 17:36 ` Michael Montalbo
2026-08-26 17:45 ` Junio C Hamano
2026-08-26 17:48 ` Michael Montalbo
2026-08-26 16:06 ` Michael Montalbo
2026-08-26 16:23 ` Junio C Hamano
2026-08-26 17:48 ` [PATCH v2] " Junio C Hamano
2026-08-27 1:22 ` Elijah Newren
2026-08-27 6:49 ` Kristoffer Haugsbakk [this message]
2026-08-27 14:38 ` Junio C Hamano
2026-08-27 16:01 ` Junio C Hamano
2026-08-27 18:15 ` [PATCH v3] " Junio C Hamano
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=cd741511-b457-4464-aab0-56d8554bf763@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mmontalbo@gmail.com \
--cc=newren@gmail.com \
/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