Re: [PATCH 4/7] revision, rev-parse: factorize incompatibility messages about --exclude-hidden

From: René Scharfe <l.s.r@web.de>
Date: Dec 6, 2023, 14:21 UTC
Message-ID: <389cd7b3-2350-4dc6-b282-e9d6e25fa68c@web.de>
In-Reply-To: <ZXByOXWo6cIy71s2@tanuki>

Am 06.12.23 um 14:08 schrieb Patrick Steinhardt:

Show 30 quoted lines

> On Wed, Dec 06, 2023 at 12:51:58PM +0100, René Scharfe wrote:
>> Use the standard parameterized message for reporting incompatible
>> options to report options that are not accepted in combination with
>> --exclude-hidden.  This reduces the number of strings to translate and
>> makes the UI a bit more consistent.
>>
>> Signed-off-by: René Scharfe <l.s.r@web.de>
>> ---
>>  builtin/rev-parse.c                |  9 ++++++---
>>  revision.c                         | 18 ++++++++++++------
>>  t/t6018-rev-list-glob.sh           |  6 ++----
>>  t/t6021-rev-list-exclude-hidden.sh |  4 ++--
>>  4 files changed, 22 insertions(+), 15 deletions(-)
>>
>> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
>> index fde8861ca4..917f122440 100644
>> --- a/builtin/rev-parse.c
>> +++ b/builtin/rev-parse.c
>> @@ -893,13 +893,15 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
>>  			}
>>  			if (opt_with_value(arg, "--branches", &arg)) {
>>  				if (ref_excludes.hidden_refs_configured)
>> -					return error(_("--exclude-hidden cannot be used together with --branches"));
>> +					return error(_("options '%s' and '%s' cannot be used together"),
>> +						     "--exclude-hidden", "--branches");
>
> The repetitive nature of this patch and subsequent ones made me wonder
> whether it would be useful to have a function similar to the
> `die_for_incompatible_*()` helper that knows to format this error
> correctly.

I wondered the same and experimented with a die_for_incompatible_opt2(). It would allow the compiler to detect typos.

Passing in the conditions as parameters is a bit tedious and unlike its for its higher-numbered siblings there is not much to win by doing that instead of using an if statement or two nested ones. We could pass in 1 if we want to integrate that function into an if cascade like above, but it would look a bit silly. And here we'd need a non-fatal version anyway.

Perhaps a build step that lists all new translatable strings would help? Nah, that would require building each commit.

A LLM-based tool to find translatable strings with the same meaning? Don't know how difficult that would be.

So I feel the same, but don't have a solution that would justify the churn of replacing the duplicate strings with function calls. :-/

René