On Mon, Jan 19, 2026 at 3:03 PM Patrick Steinhardt [off-list ref] wrote:

quoted

... 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