diff mbox series

[v2,1/3] advice: handle "rebase" in error_resolve_conflict()

Message ID 20230428125649.1719796-1-oswald.buddenhagen@gmx.de (mailing list archive)
State New, archived
Headers show
Series [v2,1/3] advice: handle "rebase" in error_resolve_conflict() | expand

Commit Message

Oswald Buddenhagen April 28, 2023, 12:56 p.m. UTC
This makes sure that we get a properly translated message rather than
inserting the command (which we failed to translate) into a generic
fallback message.

We now also BUG() out when encountering an unexpected command.

Arguably, it would be cleaner to pass the command as an enum in the
first place ...

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>
---
 advice.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Junio C Hamano April 28, 2023, 7:01 p.m. UTC | #1
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:

> This makes sure that we get a properly translated message rather than
> inserting the command (which we failed to translate) into a generic
> fallback message.

Hmph, can this be accompanied with a change to add a test to an
existing test script to demonstrate that the function can be called
with me set to "rebase" and results in a generic message?

> We now also BUG() out when encountering an unexpected command.

This needs to be reviewed by somebody who is more familiar with the
rebase/chrry-pick/revert/sequencer codepaths so that they can give a
definitive "good--I know that we never call this function with any
other value in 'me'" and that person would not be me.

> Arguably, it would be cleaner to pass the command as an enum in the
> first place ...

True, but that can be left to a different topic, I would think.

Thanks.

> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
> Cc: Junio C Hamano <gitster@pobox.com>
> ---
>  advice.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/advice.c b/advice.c
> index d6232439c3..c35ae82e7d 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -190,9 +190,10 @@ int error_resolve_conflict(const char *me)
>  		error(_("Pulling is not possible because you have unmerged files."));
>  	else if (!strcmp(me, "revert"))
>  		error(_("Reverting is not possible because you have unmerged files."));
> +	else if (!strcmp(me, "rebase"))
> +		error(_("Rebasing is not possible because you have unmerged files."));
>  	else
> -		error(_("It is not possible to %s because you have unmerged files."),
> -			me);
> +		BUG("Unhandled conflict reason '%s'", me);
>  
>  	if (advice_enabled(ADVICE_RESOLVE_CONFLICT))
>  		/*
Oswald Buddenhagen April 29, 2023, 7:18 a.m. UTC | #2
On Fri, Apr 28, 2023 at 12:01:02PM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>
>> This makes sure that we get a properly translated message rather than
>> inserting the command (which we failed to translate) into a generic
>> fallback message.
>
>Hmph, can this be accompanied with a change to add a test to an
>existing test script to demonstrate that the function can be called
>with me set to "rebase" and results in a generic message?
>
i suppose it could, but see next paragraph.

>> We now also BUG() out when encountering an unexpected command.
>
>This needs to be reviewed by somebody who is more familiar with the
>rebase/chrry-pick/revert/sequencer codepaths so that they can give a
>definitive "good--I know that we never call this function with any
>other value in 'me'" and that person would not be me.
>
assuming we care only about in-tree code, i'm just about as confident 
about this as one can reasonably be - because i grepped through the 
code, recursively looking for entry points. there are several calls via 
die_resolve_conflict() which have hard-coded `me`s (none of which is 
rebase), and two from the sequencer, where `me` comes from 
action_name(), which in turn returns one of three hard-coded strings 
(one of which is rebase). the latter is also kinda the test case, 
because it is obvious that this will be actually invoked when the 
situation occurs. it's probably also how i actually ran into the problem 
in the first place (i surely wasn't *looking* for it ...).

>> Arguably, it would be cleaner to pass the command as an enum in the
>> first place ...
>
>True, but that can be left to a different topic, I would think.
>
yes, otherwise i'd have already done it. ^^
i can make it more explicit if you prefer that.

if you agree with the reasoning, i'll prepare an update to the commit 
message and leave the patch as-is.

-- ossi
Junio C Hamano April 30, 2023, 5:06 a.m. UTC | #3
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:

> On Fri, Apr 28, 2023 at 12:01:02PM -0700, Junio C Hamano wrote:
>>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>>
>>> This makes sure that we get a properly translated message rather than
>>> inserting the command (which we failed to translate) into a generic
>>> fallback message.
>>
>>Hmph, can this be accompanied with a change to add a test to an
>>existing test script to demonstrate that the function can be called
>>with me set to "rebase" and results in a generic message?
>>
> i suppose it could, but see next paragraph.
>
>>> We now also BUG() out when encountering an unexpected command.
>>
>>This needs to be reviewed by somebody who is more familiar with the
>>rebase/chrry-pick/revert/sequencer codepaths so that they can give a
>>definitive "good--I know that we never call this function with any
>>other value in 'me'" and that person would not be me.
>>
> assuming we care only about in-tree code, i'm just about as confident
> about this as one can reasonably be - because i grepped through the
> code, recursively looking for entry points. there are several calls
> via die_resolve_conflict() which have hard-coded `me`s (none of which
> is rebase), and two from the sequencer, where `me` comes from
> action_name(), which in turn returns one of three hard-coded strings
> (one of which is rebase). the latter is also kinda the test case,
> because it is obvious that this will be actually invoked when the
> situation occurs. it's probably also how i actually ran into the
> problem in the first place (i surely wasn't *looking* for it ...).
>
>>> Arguably, it would be cleaner to pass the command as an enum in the
>>> first place ...
>>
>>True, but that can be left to a different topic, I would think.
>>
> yes, otherwise i'd have already done it. ^^
> i can make it more explicit if you prefer that.
>
> if you agree with the reasoning, i'll prepare an update to the commit
> message and leave the patch as-is.

Yeah, how you arrived the conclusion that just covering "rebase" in
addition to what the code already covers would make the if/elseif
cascade complete is a very helpful addition to the log message.
diff mbox series

Patch

diff --git a/advice.c b/advice.c
index d6232439c3..c35ae82e7d 100644
--- a/advice.c
+++ b/advice.c
@@ -190,9 +190,10 @@  int error_resolve_conflict(const char *me)
 		error(_("Pulling is not possible because you have unmerged files."));
 	else if (!strcmp(me, "revert"))
 		error(_("Reverting is not possible because you have unmerged files."));
+	else if (!strcmp(me, "rebase"))
+		error(_("Rebasing is not possible because you have unmerged files."));
 	else
-		error(_("It is not possible to %s because you have unmerged files."),
-			me);
+		BUG("Unhandled conflict reason '%s'", me);
 
 	if (advice_enabled(ADVICE_RESOLVE_CONFLICT))
 		/*