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

Currently, COMMIT_EDITMSG contains "...and an empty message aborts the
commit", regardless of whether the --allow-empty-message option is
specified or not. This is deemed confusing and unintended.

Signed-off-by: Hu Jialun <redacted>
---
 builtin/commit.c | 41 ++++++++++++++++++++++++++++-------------
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 190d215d43..61e3382db9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c

@@ -910,21 +910,36 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		}
 
 		fprintf(s->fp, "\n");
-		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL)
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\nwith '%c' will be ignored, and an empty"
-				  " message aborts the commit.\n"), comment_line_char);
-		else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
+		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL) {
+			if (allow_empty_message) {
+				status_printf(s, GIT_COLOR_NORMAL,
+					_("Please enter the commit message for your changes."
+					" Lines starting\nwith '%c' will be ignored.\n"), comment_line_char);
+			} else {
+				status_printf(s, GIT_COLOR_NORMAL,
+					_("Please enter the commit message for your changes."
+					" Lines starting\nwith '%c' will be ignored, and an empty"
+					" message aborts the commit.\n"), comment_line_char);
+			}
+		} else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
 			if (whence == FROM_COMMIT && !merge_contains_scissors)
 				wt_status_add_cut_line(s->fp);
-		} else /* COMMIT_MSG_CLEANUP_SPACE, that is. */
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\n"
-				  "with '%c' will be kept; you may remove them"
-				  " yourself if you want to.\n"
-				  "An empty message aborts the commit.\n"), comment_line_char);
+		} else { /* COMMIT_MSG_CLEANUP_SPACE, that is. */
+			if (allow_empty_message) {
+				status_printf(s, GIT_COLOR_NORMAL,
+					_("Please enter the commit message for your changes."
+					" Lines starting\n"
+					"with '%c' will be kept; you may remove them"
+					" yourself if you want to.\n"), comment_line_char);
+			} else {
+				status_printf(s, GIT_COLOR_NORMAL,
+					_("Please enter the commit message for your changes."
+					" Lines starting\n"
+					"with '%c' will be kept; you may remove them"
+					" yourself if you want to.\n"
+					"An empty message aborts the commit.\n"), comment_line_char);
+			}
+		}
 
 		/*
 		 * These should never fail because they come from our own

-- 
2.32.0

The existing code may want to see a preliminary
clean-up patch (PATCH 1/2) to move these messages to a set of
variables, so that the fix (PATCH 2/2) can swap the contents of
these variables based on the value of allow_empty_message, if it
makes the resulting code easier to follow (I haven't tried it, so
please tell me if that improved the code or not after trying to do
so ;-)).

Tried to do this and the code does seem more maintainable. I'm not
exactly sure if I did it the right way, though, so please do feel free
to point out where I have done improperly.

Also, sorry about the previous email -- I forgot to put one newline and got
the quoted text truncated. I am really new to mailing lists and might make
some silly mistakes :E

Hu Jialun (2):
  commit: reorganise duplicate commit prompt strings
  commit: remove irrelavent prompt on `--allow-empty-message`

 builtin/commit.c                          | 31 ++++++++++++++---------
 t/t7500-commit-template-squash-signoff.sh |  4 +--
 t/t7502-commit-porcelain.sh               |  4 +--
 3 files changed, 23 insertions(+), 16 deletions(-)

-- 
2.32.0

While the prefilled commit prompt is mostly the same for different
cleanup modes, those are separately repeated, which violates the DRY
principle and hinders maintainability.

Unify and reorder identical substrings to improve.

Signed-off-by: Hu Jialun <redacted>
---
 builtin/commit.c | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 190d215d43..815b408002 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c

@@ -910,21 +910,24 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		}
 
 		fprintf(s->fp, "\n");
-		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL)
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\nwith '%c' will be ignored, and an empty"
-				  " message aborts the commit.\n"), comment_line_char);
+		const char *msg_enter_prompt = _("Please enter the commit message for your changes.");
+		const char *keep_char_prompt = _("Lines starting with '%c' will be kept;"
+						 " you may remove them yourself if you want to.");
+		const char *ignore_char_prompt = _("Lines starting with '%c' will be ignored.");
+		const char *empty_msg_abort_prompt = _("An empty message aborts the commit.");
+		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL) {
+			status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);
+			status_printf_ln(s, GIT_COLOR_NORMAL, ignore_char_prompt, comment_line_char);
+			status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+		}
 		else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
 			if (whence == FROM_COMMIT && !merge_contains_scissors)
 				wt_status_add_cut_line(s->fp);
-		} else /* COMMIT_MSG_CLEANUP_SPACE, that is. */
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\n"
-				  "with '%c' will be kept; you may remove them"
-				  " yourself if you want to.\n"
-				  "An empty message aborts the commit.\n"), comment_line_char);
+		} else { /* COMMIT_MSG_CLEANUP_SPACE, that is. */
+			status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);
+			status_printf_ln(s, GIT_COLOR_NORMAL, keep_char_prompt, comment_line_char);
+			status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+		}
 
 		/*
 		 * These should never fail because they come from our own

-- 
2.32.0

Even when the `--allow-empty-message` option is given, "git
commit" offers an interactive editor session with prefilled
message that says the commit will be aborted if the buffer is
emptied, which is wrong.

Remove the "an empty message aborts" part from the message when
the option is given to fix it.

Helped-by: Junio C Hamano [off-list ref]
Signed-off-by: Hu Jialun <redacted>
---
The tests are also amended in line with the new string.

 builtin/commit.c                          | 8 ++++++--
 t/t7500-commit-template-squash-signoff.sh | 4 ++--
 t/t7502-commit-porcelain.sh               | 4 ++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 815b408002..b681dcc83c 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c

@@ -918,7 +918,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL) {
 			status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);
 			status_printf_ln(s, GIT_COLOR_NORMAL, ignore_char_prompt, comment_line_char);
-			status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+			if (!allow_empty_message) {
+				status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+			}
 		}
 		else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
 			if (whence == FROM_COMMIT && !merge_contains_scissors)

@@ -926,7 +928,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		} else { /* COMMIT_MSG_CLEANUP_SPACE, that is. */
 			status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);
 			status_printf_ln(s, GIT_COLOR_NORMAL, keep_char_prompt, comment_line_char);
-			status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+			if (!allow_empty_message) {
+				status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+			}
 		}
 
 		/*

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

-- 
2.32.0

Hi Jialun,

On 2021-07-08 00:23:07+0800, Hu Jialun [off-list ref] wrote:

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

+		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL) {
+			status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);

builtin/commit.c:919:4: error: format not a string literal and no format arguments [-Werror=format-security]
  919 |    status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);

msg_enter_prompt will come from translator and may have '%' inside it.

We can solve it by inserting "%s" there.

However, I think we shouldn't take this route, because splitting likes this
will make a translation lego. I can't speak for Junio, but from my
observation, it's preferred to have 3 variables for 3 full-text, and
we will pick the suitable text in each if-leg.

+			status_printf_ln(s, GIT_COLOR_NORMAL, ignore_char_prompt, comment_line_char);
+			status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+		}
 		else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
 			if (whence == FROM_COMMIT && !merge_contains_scissors)
 				wt_status_add_cut_line(s->fp);
-		} else /* COMMIT_MSG_CLEANUP_SPACE, that is. */
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\n"
-				  "with '%c' will be kept; you may remove them"
-				  " yourself if you want to.\n"
-				  "An empty message aborts the commit.\n"), comment_line_char);
+		} else { /* COMMIT_MSG_CLEANUP_SPACE, that is. */
+			status_printf_ln(s, GIT_COLOR_NORMAL, msg_enter_prompt);
+			status_printf_ln(s, GIT_COLOR_NORMAL, keep_char_prompt, comment_line_char);
+			status_printf_ln(s, GIT_COLOR_NORMAL, empty_msg_abort_prompt);
+		}

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.

 
 		/*
 		 * These should never fail because they come from our own
-- 
2.32.0

-- 
Danh

Hu Jialun wrote:

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

-- 
Felipe Contreras

Junio C Hamano wrote:

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!

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?

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

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

On 2021-07-08 23:19:11+0800, Hu Jialun [off-list ref] wrote:

Junio C Hamano wrote:

quoted

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.

I think this approach is the most expensive one, _() needs to query
the gettext infrastructure, which is usually costly.
However, I think that cost doesn't matter much since we're about to
open an editor soon.

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

install_branch_config() uses this style.

3.
const char *hint_foo = allow_empty_message ?
                       _("...") :
		       _("....");

builtin/remote.c:show_local_info_item() writes:

	const char *msg;
	if (condition)
		msg = _("some message");
	else
		msg = _("other message");

So, I guess it's fine either way. And people will need to see the
patch to see which one is better.

......
status_printf(s, GIT_COLOR_NORMAL, hint_foo, comment_line_char);

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

Felipe Contreras wrote:

quoted

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:

quoted

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

Noted with thanks!

quoted

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?

Yes, when apply both 2 patches, the test passed, however, the test
doesn't pass with only 1/2 applied. Let's imagine in a near future,
some developers need to bisect some problems with Git with automation
scripts, and git-bisect stops at 1/2, since the tests report failure,
"git bisect run" will mark this change as "bad commit", thus render
git-bisect hard to use. We should make sure all tests pass on all
commit.

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.

Let's imagine an artificial language which have 2 words "linos" and
"linas" which is both translated to English as "lines", translators
need full context to decide which word should be chosen. Things maybe
complicated with language with gender, word-cases, etc...

There're some problems reported on and off this list [1]

- 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.

Documentation/CodingGuidelines said so ;)
I don't think somebody adding random statements is a valid concern for
brace, I think it's expected to analyse the code context before doing
real-work on project. Furthermore, -Wmisleading-indentation is your
friends.


1: https://lore.kernel.org/git/20210509215250.33215-1-alexhenrie24@gmail.com/

-- 
Danh

Strings of hint messages inserted into editor on interactive commit was
scattered in-line, rendering the code harder to understand at first
glance.

Extract those messages out into separate variables to make the code
outline easier to follow.

Helped-by: Junio C Hamano [off-list ref]
Helped-by: Đoàn Trần Công Danh [off-list ref]
Signed-off-by: Hu Jialun <redacted>
---
 builtin/commit.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 190d215d43..e68d139dee 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c

@@ -889,6 +889,14 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		int ident_shown = 0;
 		int saved_color_setting;
 		struct ident_split ci, ai;
+		const char *hint_cleanup_all = _("Please enter the commit message for your changes."
+						 " Lines starting\nwith '%c' will be ignored,"
+						 " and an empty message aborts the commit.\n");
+		const char *hint_cleanup_space = _("Please enter the commit message for your changes."
+						   " Lines starting\n"
+						   "with '%c' will be kept; you may remove them"
+						   " yourself if you want to.\n"
+						   "An empty message aborts the commit.\n");
 
 		if (whence != FROM_COMMIT) {
 			if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&

@@ -911,20 +919,12 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 
 		fprintf(s->fp, "\n");
 		if (cleanup_mode == COMMIT_MSG_CLEANUP_ALL)
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\nwith '%c' will be ignored, and an empty"
-				  " message aborts the commit.\n"), comment_line_char);
+			status_printf(s, GIT_COLOR_NORMAL, hint_cleanup_all, comment_line_char);
 		else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS) {
 			if (whence == FROM_COMMIT && !merge_contains_scissors)
 				wt_status_add_cut_line(s->fp);
 		} else /* COMMIT_MSG_CLEANUP_SPACE, that is. */
-			status_printf(s, GIT_COLOR_NORMAL,
-				_("Please enter the commit message for your changes."
-				  " Lines starting\n"
-				  "with '%c' will be kept; you may remove them"
-				  " yourself if you want to.\n"
-				  "An empty message aborts the commit.\n"), comment_line_char);
+			status_printf(s, GIT_COLOR_NORMAL, hint_cleanup_space, comment_line_char);
 
 		/*
 		 * These should never fail because they come from our own

-- 
2.32.0

Even when the `--allow-empty-message` option is given, "git commit"
offers an interactive editor session with prefilled message that says
the commit will be aborted if the buffer is emptied, which is wrong.

Remove the "an empty message aborts" part from the message when the
option is given to fix it.

Helped-by: Junio C Hamano [off-list ref]
Helped-by: Đoàn Trần Công Danh [off-list ref]
Helped-by: Felipe Contreras [off-list ref]
Signed-off-by: Hu Jialun <redacted>
---
 builtin/commit.c                          | 25 +++++++++++++++--------
 t/t7500-commit-template-squash-signoff.sh |  2 +-
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index e68d139dee..cfbc83751a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c

@@ -889,15 +889,22 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		int ident_shown = 0;
 		int saved_color_setting;
 		struct ident_split ci, ai;
-		const char *hint_cleanup_all = _("Please enter the commit message for your changes."
-						 " Lines starting\nwith '%c' will be ignored,"
-						 " and an empty message aborts the commit.\n");
-		const char *hint_cleanup_space = _("Please enter the commit message for your changes."
-						   " Lines starting\n"
-						   "with '%c' will be kept; you may remove them"
-						   " yourself if you want to.\n"
-						   "An empty message aborts the commit.\n");
-
+		const char *hint_cleanup_all = allow_empty_message ?
+			_("Please enter the commit message for your changes."
+			  " Lines starting\nwith '%c' will be ignored.\n") :
+			_("Please enter the commit message for your changes."
+			  " Lines starting\nwith '%c' will be ignored, and an empty"
+			  " message aborts the commit.\n");
+		const char *hint_cleanup_space = allow_empty_message ?
+			_("Please enter the commit message for your changes."
+			  " Lines starting\n"
+			  "with '%c' will be kept; you may remove them"
+			  " yourself if you want to.\n") :
+			_("Please enter the commit message for your changes."
+			  " Lines starting\n"
+			  "with '%c' will be kept; you may remove them"
+			  " yourself if you want to.\n"
+			  "An empty message aborts the commit.\n");
 		if (whence != FROM_COMMIT) {
 			if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
 				!merge_contains_scissors)

diff --git a/t/t7500-commit-template-squash-signoff.sh b/t/t7500-commit-template-squash-signoff.sh
index 7d02f79c0d..54c2082acb 100755
--- a/t/t7500-commit-template-squash-signoff.sh
+++ b/t/t7500-commit-template-squash-signoff.sh

@@ -498,7 +498,7 @@ 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.
+# with '#' will be ignored.
 #
 # Author:    A U Thor <author@example.com>
 #

-- 
2.32.0

Hu Jialun [off-list ref] writes:

That would easily make lines that are overly long.  Perhaps fold
them like so?

		const char *hint_cleanup_all =
			_("Please enter the commit message for your changes."
			  " Lines starting\nwith '%c' will be ignored,"
			  " and an empty message aborts the commit.\n");