public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jiang Xin <worldhello.net@gmail.com>,
	Git List <git@vger.kernel.org>,
	Jiang Xin <zhiyou.jx@alibaba-inc.com>
Subject: Re: [PATCH] help: report on whether or not gettext is enabled
Date: Mon, 19 Jan 2026 08:03:47 +0100	[thread overview]
Message-ID: <aW3XUxaomqGbtpEj@pks.im> (raw)
In-Reply-To: <xmqqo6mta7bg.fsf@gitster.g>

On Fri, Jan 16, 2026 at 07:46:59AM -0800, Junio C Hamano wrote:
> > diff --git a/help.c b/help.c
> > index 20e114432d..96d70d8e6c 100644
> > --- a/help.c
> > +++ b/help.c
> > @@ -799,6 +799,11 @@ void get_version_info(struct strbuf *buf, int show_build_options)
> >  
> >  		if (fsmonitor_ipc__is_supported())
> >  			strbuf_addstr(buf, "feature: fsmonitor--daemon\n");
> > +#if defined NO_GETTEXT
> > +		strbuf_addstr(buf, "gettext: disabled\n");
> > +#else
> > +		strbuf_addstr(buf, "gettext: enabled\n");
> > +#endif
> 
> Presumably, we do not care too much about the version of this thing
> unlike ...
> 
> >  #if defined LIBCURL_VERSION
> >  		strbuf_addf(buf, "libcurl: %s\n", LIBCURL_VERSION);
> >  #endif
> 
> ... 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
extends to libcurl, where it would be more helpful to print "libcurl:
disabled" if it's not used.

I don't feel particularly strong about this though.

Patrick

  parent reply	other threads:[~2026-01-19  7:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16  2:29 [PATCH] help: report on whether or not gettext is enabled Jiang Xin
2026-01-16 15:46 ` Junio C Hamano
2026-01-17 13:59   ` [PATCH v2] " Jiang Xin
2026-01-19  7:03   ` Patrick Steinhardt [this message]
2026-01-19 10:17     ` [PATCH] " Jiang Xin
2026-01-20  0:15     ` Junio C Hamano
2026-01-20  5:47       ` Patrick Steinhardt

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=aW3XUxaomqGbtpEj@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=worldhello.net@gmail.com \
    --cc=zhiyou.jx@alibaba-inc.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