From: Junio C Hamano <gitster@pobox.com>
To: Emily Shaffer <emilyshaffer@google.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org, "Victoria Dye" <vdye@github.com>
Subject: Re: [PATCH v3 2/3] CodingGuidelines: hint why we value clearly written log messages
Date: Wed, 20 Apr 2022 01:23:24 -0700 [thread overview]
Message-ID: <xmqqbkwwrwn7.fsf@gitster.g> (raw)
In-Reply-To: Yl89hMGLN3DqIkJ7@google.com
Emily Shaffer <emilyshaffer@google.com> writes:
> On Thu, Apr 14, 2022 at 04:04:59PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> ...
>> For our CodingGuidelines I think it would be useful to have some version
>> of "if you can explain something with prose or tests, prefer
>> tests".
I was going to ignore this part as it is merely showing personal
preference, but I guess I need to weigh in here.
Demonstrating what you meant to say in the log message with tests is
fine, but that should be in addition to prose, explaining how the
scenario is set up and what the user wanted to do, before showing
that a command is giving an outcome that does not help what the user
wanted to do.
IOW, in our CodingGUidelines, we should have "tests can be a good
way to augument what you want to say, but explain it well to those
who are not so familiar with the area." You do not necessarily have
to explain it to 5 year old, but the audience should not have to be
whoever writes the patch themself to understand it.
> So as I'm deciding what to review, I definitely would prefer Victoria's
> commit message. Plus, like I mentioned, it gives the extra safeguard of
> allowing reviewers to check: does the patch actually do what the author
> meant for it to do? If we're never told what the author meant for it to
> do, then we are missing information needed for that part of the review.
I have nothing to add here.
> Anyway, I haven't watched Victoria's talk yet, but I will do so soon :)
I do not necessarily agree with the presentation order in a proposed
log message she suggests, but overall, it's good investment of your
time. Highly recommended.
next prev parent reply other threads:[~2022-04-20 8:23 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbkwwrwn7.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=vdye@github.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.
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 NNTP newsgroup(s).