From: Emily Shaffer <emilyshaffer@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 3/3] SubmittingPatches: explain why we care about log messages
Date: Thu, 3 Mar 2022 16:10:19 -0800 [thread overview]
Message-ID: <YiFY693P6E/eVS3k@google.com> (raw)
In-Reply-To: <20220127190259.2470753-4-gitster@pobox.com>
On Thu, Jan 27, 2022 at 11:02:59AM -0800, Junio C Hamano wrote:
>
> Extend the "describe your changes well" section to cover whom we are
> trying to help by doing so in the first place.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/SubmittingPatches | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 7225a0fb52..a6121d1d42 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -110,6 +110,35 @@ run `git diff --check` on your changes before you commit.
> [[describe-changes]]
> === Describe your changes well.
>
> +The log message that explains your changes is just as important as the
> +changes themselves. Your code may be clearly written with in-code
> +comment to sufficiently explain how it works with the surrounding
> +code, but those who need to fix or enhance your code in the future
> +will need to know _why_ your code does what it does, for a few
> +reasons:
> +
> +. Your code may be doing something differently from what you wanted it
> + to do. Writing down what you actually wanted to achieve will help
> + them fix your code and make it do what it should have been doing
> + (also, you often discover your own bugs yourself, while writing the
> + log message to summarize the thought behind it).
> +
> +. Your code may be doing things that were only necessary for your
> + immediate needs (e.g. "do X to directories" without implementing or
> + even designing what is to be done on files). Writing down why you
> + excluded what the code does not do will help guide future developers.
> + Writing down "we do X to directories, because directories have
> + characteristic Y" would help them infer "oh, files also have the same
> + characteristic Y, so perhaps doing X to them would also make sense?".
> + Saying "we don't do the same X to files, because ..." will help them
> + decide if the reasoning is sound (in which case they do not waste
> + time extending your code to cover files), or reason differently (in
> + which case, they can explain why they extend your code to cover
> + files, too).
> +
> +The goal of your log message is to convey the _why_ behind your
> +change to help future developers.
> +
This is pretty compelling. Is it clear enough why we care about this in
the commit message, as opposed to in the patch description (cover letter
or post-"---" blurb)? Is it too obvious to explicitly mention that the
commit message is the first thing we try to make sense of during a 'git
blame' or 'git bisect'?
Either way, I think this is an improvement on the doc as it was before.
Reviewed-by: Emily Shaffer <emilyshaffer@google.com>
> The first line of the commit message should be a short description (50
> characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
> and should skip the full stop. It is also conventional in most cases to
> --
> 2.35.0-177-g7d269f5170
>
next prev parent reply other threads:[~2022-03-04 0:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-23 20:37 [RFC] Contributor doc: more on the proposed log message Junio C Hamano
2022-01-23 21:32 ` brian m. carlson
2022-01-26 11:07 ` Kaartic Sivaraam
2022-01-26 23:42 ` [PATCH v2 0/3] contributor doc update around log messages Junio C Hamano
2022-01-26 23:42 ` [PATCH v2 1/3] SubmittingPatches: write problem statement in the log in the present tense Junio C Hamano
2022-01-26 23:42 ` [PATCH v2 2/3] CodingGuidelines: hint why we value clearly written log messages Junio C Hamano
2022-01-27 7:31 ` Eric Sunshine
2022-01-27 18:35 ` Junio C Hamano
2022-01-26 23:42 ` [PATCH v2 3/3] SubmittingPatches: explain why we care about " Junio C Hamano
2022-01-27 19:02 ` [PATCH v3 0/3] contributor doc update around " Junio C Hamano
2022-03-04 0:12 ` Emily Shaffer
2022-01-27 19:02 ` [PATCH v3 1/3] SubmittingPatches: write problem statement in the log in the present tense Junio C Hamano
2022-03-03 23:59 ` Emily Shaffer
2022-03-04 0:23 ` Junio C Hamano
2022-03-04 23:41 ` Emily Shaffer
2022-01-27 19:02 ` [PATCH v3 2/3] CodingGuidelines: hint why we value clearly written log messages Junio C Hamano
2022-03-04 0:07 ` Emily Shaffer
2022-03-04 0:27 ` Junio C Hamano
2022-04-14 6:51 ` Junio C Hamano
2022-04-14 14:04 ` Ævar Arnfjörð Bjarmason
2022-04-19 22:53 ` Emily Shaffer
2022-04-20 8:23 ` Junio C Hamano
2022-01-27 19:02 ` [PATCH v3 3/3] SubmittingPatches: explain why we care about " Junio C Hamano
2022-03-04 0:10 ` Emily Shaffer [this message]
2022-03-04 0:29 ` Junio C Hamano
2022-03-04 9:52 ` log messages > comments (was: [PATCH v3 3/3] SubmittingPatches: explain why we care about log messages) Ævar Arnfjörð Bjarmason
2022-03-04 19:41 ` log messages > comments Junio C Hamano
2022-03-04 21:30 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YiFY693P6E/eVS3k@google.com \
--to=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).