From: Junio C Hamano <gitster@pobox.com>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 3/3] Capitalization and punctuation fixes to some user visible messages
Date: Fri, 28 Apr 2023 11:57:09 -0700 [thread overview]
Message-ID: <xmqqttwzded6.fsf@gitster.g> (raw)
In-Reply-To: <20230428125649.1719796-3-oswald.buddenhagen@gmx.de> (Oswald Buddenhagen's message of "Fri, 28 Apr 2023 14:56:49 +0200")
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
> These are conscious violations of the usual rules for error messages,
> based on this reasoning:
> - If an error message is directly followed by another sentence, it needs
> to be properly terminated with a period, lest the grammar looks broken
> and becomes hard to read.
> - That second sentence isn't actually an error message any more, so it
> should abide to conventional language rules for good looks and
> legibility. Arguably, these should be converted to advice messages
> (which the user can squelch, too), but that's a much bigger effort to
> get right.
I think both of the above are good guidelines to follow, with a hint
for a longer-term plan. Good description.
> - Neither of these apply to the first hunk in do_exec(), but this
> two-line message looks just too much like a real sentence to not
> terminate it. Also, leaving it alone would make it asymmetrical to
> the other hunk.
I do not have a strong opinion on this one, in the sense that if
somebody writes a patch to terminate the sentence with the above
justification, I do not think I would object to it, and if somebody
omits this change from a patch like this, because the above two
guidelines do not apply to it, I would not object to it, either.
> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
> Cc: Junio C Hamano <gitster@pobox.com>
We generally do not want Cc: in the trailers. Can you move them
after the three-dash lines (which I think is still read by
send-email) next time you create more patches and throw them at the
list?
Will queue.
> ---
> v2:
> - tried to make commit message more convincing
> - put it last in the series, to make the less controversial changes
> easier to apply
> ---
> builtin/pull.c | 2 +-
> sequencer.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/pull.c b/builtin/pull.c
> index 56f679d94a..bb2ddc93ab 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -1044,7 +1044,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
> if (!opt_autostash)
> require_clean_work_tree(the_repository,
> N_("pull with rebase"),
> - _("please commit or stash them."), 1, 0);
> + _("Please commit or stash them."), 1, 0);
>
> if (get_rebase_fork_point(&rebase_fork_point, repo, *refspecs))
> oidclr(&rebase_fork_point);
> diff --git a/sequencer.c b/sequencer.c
> index 0677c9ab09..21748bbfb0 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3629,13 +3629,13 @@ static int do_exec(struct repository *r, const char *command_line)
> "\n"),
> command_line,
> dirty ? _("and made changes to the index and/or the "
> - "working tree\n") : "");
> + "working tree.\n") : "");
> if (status == 127)
> /* command not found */
> status = 1;
> } else if (dirty) {
> warning(_("execution succeeded: %s\nbut "
> - "left changes to the index and/or the working tree\n"
> + "left changes to the index and/or the working tree.\n"
> "Commit or stash your changes, and then run\n"
> "\n"
> " git rebase --continue\n"
next prev parent reply other threads:[~2023-04-28 18:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 16:22 [PATCH 1/3] Capitalization and punctuation fixes to some user visible messages Oswald Buddenhagen
2023-03-23 16:22 ` [PATCH 2/3] sequencer: actually translate report in do_exec() Oswald Buddenhagen
2023-03-23 20:43 ` Junio C Hamano
2023-03-23 21:20 ` Oswald Buddenhagen
2023-03-23 21:25 ` Junio C Hamano
2023-03-23 21:53 ` Oswald Buddenhagen
2023-03-23 16:22 ` [PATCH 3/3] advice: translate all actions in error_resolve_conflict() Oswald Buddenhagen
2023-03-24 14:44 ` Junio C Hamano
2023-03-23 20:39 ` [PATCH 1/3] Capitalization and punctuation fixes to some user visible messages Junio C Hamano
2023-03-23 21:10 ` Oswald Buddenhagen
2023-04-28 12:56 ` [PATCH v2 1/3] advice: handle "rebase" in error_resolve_conflict() Oswald Buddenhagen
2023-04-28 12:56 ` [PATCH v2 2/3] sequencer: actually translate report in do_exec() Oswald Buddenhagen
2023-04-28 19:02 ` Junio C Hamano
2023-04-28 12:56 ` [PATCH v2 3/3] Capitalization and punctuation fixes to some user visible messages Oswald Buddenhagen
2023-04-28 18:57 ` Junio C Hamano [this message]
2023-04-28 19:09 ` Junio C Hamano
2023-04-28 19:01 ` [PATCH v2 1/3] advice: handle "rebase" in error_resolve_conflict() Junio C Hamano
2023-04-29 7:18 ` Oswald Buddenhagen
2023-04-30 5:06 ` Junio C Hamano
2023-08-07 17:09 ` [PATCH v3] " Oswald Buddenhagen
2023-08-07 20:20 ` Junio C Hamano
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=xmqqttwzded6.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=oswald.buddenhagen@gmx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.