Re: [PATCH] help: report on whether or not gettext is enabled

From: Jiang Xin <worldhello.net@gmail.com>
Date: Jan 19, 2026, 10:17 UTC
Message-ID: <CANYiYbGn-ANF4jT2Lef+uL=sfcVWukBH7J71VaapGkaDaYHFZA@mail.gmail.com>
In-Reply-To: <aW3XUxaomqGbtpEj@pks.im>

On Mon, Jan 19, 2026 at 3:03 PM Patrick Steinhardt <ps@pks.im> wrote:

Show 23 quoted lines

> > ... we do for the curl library, so only reporting "enabled" does
> > feel perfectly OK to me.
> >
> > I would prefer not to see the "disabled" entry myself, by the way.
> > Combined with the vintage of Git binary that had these help text,
> > the fact that an "enabled" line is missing is enough clue to
> > diagnose.  I know you mimicked the Rust entry before this point
> > (just above the precontext of the hunk), but I think we should fix
> > it to drop the "disabled" entry from there.
> >
> > Cc'ed the author of cb2badb4 (help: report on whether or not Rust is
> > enabled, 2025-10-02).
>
> One reason why I personally prefer to have enabled/disabled is that it
> allows you to discern the following two cases:
>
>   - You have a modern version of Git that doesn't have gettext.
>
>   - You have an old version of Git that doesn't know to print
>     information about whether or not gettext is enabled.
>
> If we don't print the info at all when gettext is disabled then it's
> impossible to tell these two cases apart. That argument in my mind also

Both `git version --build-options` and `git bugreport` display the Git version number. This allows us to identify whether we're looking at an old version that predates the gettext feature, or a modern version where we can expect gettext status to be explicitly reported (even if disabled).

In reroll v2, I considered outputting GIT_LOCALE_PATH instead of "enabled" for gettext, but that would have required refactoring git_setup_gettext() in gettext.c. The benefit didn't seem worth the effort, so I dropped it.

-- Jiang Xin