Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonas Rebmann <kernel@schlaraffenlan.de>
Cc: git@vger.kernel.org,  Chris Down <chris@chrisdown.name>,
	 Jeff King <peff@peff.net>,
	 Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v3 1/2] bisect: use selected alternate terms in status output
Date: Fri, 17 Apr 2026 12:50:49 -0700	[thread overview]
Message-ID: <xmqqjyu5weli.fsf@gitster.g> (raw)
In-Reply-To: <20260417-bisect-terms-v3-1-d659fa547261@schlaraffenlan.de> (Jonas Rebmann's message of "Fri, 17 Apr 2026 18:48:30 +0200")

Jonas Rebmann <kernel@schlaraffenlan.de> writes:

>  	if (!state.nr_good && !state.nr_bad)
> -		bisect_log_printf(_("status: waiting for both good and bad commits\n"));
> +		bisect_log_printf(_("status: waiting for both '%s' and '%s' commits\n"),
> +				  terms->term_good, terms->term_bad);

I think this was new in v2 (which I somehow did not pick up).  Good
finding, but not limited to this one, I wonder how these custom
terms interact with localization.  The 'quotes' around these terms
do help by hinting that they are not a normal adjectives given to
the noun 'commits', so that might be good enough, but that still
assumes that the .term_good and .term_bad, even when they are not
'good' and 'bad', are good adjectives that can apply to 'commits'.
I'd expect in most use cases that would hold, but the command does
not prevent you from calling more recent ones 'dog commits' and the
ones before the transition point 'cat commits' ;-).

Of course, rephrasing the above to

	waiting for both commit(s) marked as '%s' and as '%s'

would be ultra-awkward, even if it may be the safest.  So I dunno.

> -				error(_("unable to verify %s on good"
> -					" revision"), command.buf);
> +				error(_("unable to verify %s on %s revision"),
> +				      command.buf, terms->term_good);

And from that point of view, this unquoted "ON good REVISION" might
become a problem, because it asssumes that .term_good would be
readable as an adjective given to the noun 'revision', which might
not hold true even without translation.  The command.buf contains a
command with its arguments, and .term_good contains the custom term.
Perhaps both should be placed in '%s' quotes?

>  				res = BISECT_FAILED;
>  				break;
>  			}
>  			if (rc == res) {
> -				error(_("bogus exit code %d for good revision"),
> -				      rc);
> +				error(_("bogus exit code %d for %s revision"),
> +				      rc, terms->term_good);

Ditto for quoting 'good' that is no longer a normal adjective that
adorns the noun 'revision', in the context of a translated message.

> @@ -1314,7 +1317,7 @@ static int bisect_run(struct bisect_terms *terms, int argc, const char **argv)
>  			puts(_("bisect run success"));
>  			res = BISECT_OK;
>  		} else if (res == BISECT_INTERNAL_SUCCESS_1ST_BAD_FOUND) {
> -			puts(_("bisect found first bad commit"));
> +			printf(_("bisect found first %s commit\n"), terms->term_bad);

Ditto for quoting 'bad' here.

  reply	other threads:[~2026-04-17 19:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-17 16:48 [PATCH v3 0/2] Avoid hardcoded "good"/"bad" bisect terms Jonas Rebmann
2026-04-17 16:48 ` [PATCH v3 1/2] bisect: use selected alternate terms in status output Jonas Rebmann
2026-04-17 19:50   ` Junio C Hamano [this message]
2026-04-17 16:48 ` [PATCH v3 2/2] rev-parse: use selected alternate terms to look up refs Jonas Rebmann

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=xmqqjyu5weli.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=chris@chrisdown.name \
    --cc=git@vger.kernel.org \
    --cc=kernel@schlaraffenlan.de \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    /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