Re: [PATCH] commit: remove irrelavent prompt on `--allow-empty-message`

From: Hu Jialun <hujialun@comp.nus.edu.sg>
Date: Jul 8, 2021, 15:19 UTC
Message-ID: <20210708151911.2524122-1-hujialun@comp.nus.edu.sg>
In-Reply-To: <20210707162308.2438170-1-hujialun@comp.nus.edu.sg>

Junio C Hamano wrote:

Show 13 quoted lines

> char *hint_cleanup_all =
> _("Please enter the ... , and an empty message aborts the commit.\n");
> char *hint_cleanup_space =
> _("Please enter the ... if you want to.\n"
>       "An empty message aborts the commit.\n");
>
> if (allow_empty_message) {
>         hint_cleanup_all = _("...");
>         hint_cleanup_space = _("...");
> }
>
> ... the if/elseif cascade in which calls to status_printf() are made
> ... using these variables

Would it be better this way or just using the ternary operator in-line instead? If the latter, should it still be separated into another variable or just embedded in the status_printf call? Using the ternary operator does require to separate checks of allow_empty_message, but might as well save us an `if` construct to reassign the variable.

In other words, which of the following 3 is the most acceptable?

1. As Junio suggested, quoted above.

2.
status_printf(s, GIT_COLOR_NORMAL, allow_empty_message ?
                                   _("...") :
				   _("...."), comment_line_char);

3.
const char *hint_foo = allow_empty_message ?
                       _("...") :
		       _("....");
......
status_printf(s, GIT_COLOR_NORMAL, hint_foo, comment_line_char);

--------------------------------------------------------------------

Felipe Contreras wrote:

> In git the style is to avoid braces if the content of the condition is a
> single line.

Đoàn Trần Công Danh wrote:

> In Git project, it's enforced to have -Wdeclaration-after-statement,
> IOW, move all declaration before statement.

Noted with thanks!

Show 6 quoted lines

> After changing those texts, the tests should be updated, too.
> It's a customary service for the next developer, who needs to bisect
> this project to have all test-cases pass on each changes.
> 
> With this change, t7500.50 and t7502.37 runs into failures.
> Please fix them here, instead of next change.

I did change test cases accordingly in the second patch (excerpt below), and both tests did pass afterwards. Was there something wrong with it?

Show 30 quoted lines

> diff --git a/t/t7500-commit-template-squash-signoff.sh b/t/t7500-commit-template-squash-signoff.sh
> index 7d02f79c0d..812ca45043 100755
> --- a/t/t7500-commit-template-squash-signoff.sh
> +++ b/t/t7500-commit-template-squash-signoff.sh
> @@ -497,8 +497,8 @@ test_expect_success 'invalid message options when using --fixup' '
> 
>  cat >expected-template <<EOF
> 
> -# Please enter the commit message for your changes. Lines starting
> -# with '#' will be ignored, and an empty message aborts the commit.
> +# Please enter the commit message for your changes.
> +# Lines starting with '#' will be ignored.
>  #
>  # Author:    A U Thor <author@example.com>
>  #
> diff --git a/t/t7502-commit-porcelain.sh b/t/t7502-commit-porcelain.sh
> index 38a532d81c..a5217872ca 100755
> --- a/t/t7502-commit-porcelain.sh
> +++ b/t/t7502-commit-porcelain.sh
> @@ -608,8 +608,8 @@ test_expect_success 'cleanup commit messages (strip option,-F,-e)' '
> 
>  echo "sample
> 
> -# Please enter the commit message for your changes. Lines starting
> -# with '#' will be ignored, and an empty message aborts the commit." >expect
> +# Please enter the commit message for your changes.
> +# Lines starting with '#' will be ignored." >expect
> 
>  test_expect_success 'cleanup commit messages (strip option,-F,-e): output' '
>  	test_cmp expect actual

--------------------------------------------------------------------

And some perhaps rather noob questions below, as an (overly) curious newcomer,

- Why is the "lego" style breakdown of translation strings unrecommended?
  I suppose it might be in consideration of possibly different linguistic
  sequences across languages but I'm not so sure.

- What is the rationale behind prohibiting braces around single line
  constructs? It seems somewhat error-prone since somebody else could
  later be adding statements into the body without putting the curly
  braces.

- When replying to multiple comments in multiple emails (like in this very
  email), would it be better to send multiple emails as replies to individual
  comments or do it in one email? If the latter, which previous message should
  the single reply be In-Reply-To?

Thanks in advance, Hu Jialun