From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 2/3] test-lib: simplify lsan results check
Date: Thu, 9 Jan 2025 11:00:44 +0100 [thread overview]
Message-ID: <Z3-eTDsHQ9Nu1er9@pks.im> (raw)
In-Reply-To: <20250109075750.GC2735258@coredump.intra.peff.net>
On Thu, Jan 09, 2025 at 02:57:50AM -0500, Jeff King wrote:
> On Tue, Jan 07, 2025 at 08:37:33AM +0100, Patrick Steinhardt wrote:
>
> > On Tue, Jan 07, 2025 at 02:07:52AM -0500, Jeff King wrote:
> > > We want to know if there are any leaks logged by LSan in the results
> > > directory, so we run "find" on the containing directory and pipe it to
> > > xargs. We can accomplish the same thing by just globbing in the shell
> > > and passing the result to grep, which has a few advantages:
> > >
> > > - it's one fewer process to run
> > >
> > > - we can glob on the TEST_RESULTS_SAN_FILE pattern, which is what we
> > > checked at the beginning of the function, and is the same glob use
> >
> > s/use/used
> >
> > I'm always a bit thrown off by your style of bulleted lists, where they
> > feel like sentences but start with a lower-case letter, and sometimes
> > they do and sometimes they don't end with punctuation. Maybe it's just
> > me not being a native speaker and it's a natural thing to do in English.
> > In any case, it's nothing that really matters in the end, but would be
> > happy to learn if this is indeed something you tend to do in English.
>
> Heh. Yeah, I've seen you mention them before and I've been tempted to
> start a big discussion. But I never felt like it was worth it. But
> tonight's your lucky night. ;)
>
> In short: I think it's a style question. I perceive them as
> continuations of the sentence that has the ":". Though admittedly I do
> not always grammatically continue that sentence. So for example I could:
>
> - have one bullet item that completes the sentence.
>
> - and then another that likewise completes it.
>
> ;) I think many style guides would frown on that. Especially with the
> periods at the end (you might argue that they should be semicolons).
>
> In the example you quoted above they don't grammatically continue the
> sentence, so arguably what I'm saying doesn't even apply. But I also
> kind of think of the list items as sentence fragments. That sometimes
> happen to make a full sentence. Or need punctuation because that
> fragments gets so long it contains multiple sentences.
>
> I dunno. You asked if it is something you tend to do in English. It is
> something _I_ tend to do in English, but I think most style guides would
> suggest against it (but then, most also suggest against bulleted lists
> in the first place). (They probably also suggest against lots of
> parentheses). So I wouldn't necessarily copy me.
>
> My general feeling is that unless a commit message is inaccurate or hard
> to understand, we should mostly let it pass (even typos). Yes, they are
> an artifact that is enshrined in the history. But at some point they are
> also just a written communication between developers, and we all have
> our own voices and styles. And make mistakes. Polishing them is
> something we _can_ do collaboratively, but there are diminishing
> returns.
Yup, agreed. It's a minor detail and I'm happy to gloss over it in the
future.
> In case it is not clear, I would not say the same for documentation,
> error messages, etc. Those are artifacts that hits a wider audience, and
> we have a tool for polishing them together: git.
>
> And people should still proofread and correct their own messages before
> sending. Believe it or not, I do always take a final pass when sending
> out my commits and still manage to have errors. ;) A lot of times I end
> up improving clarity and wording on the final pass, but end up
> introducing a typo (I'm pretty sure that the use/used above was me
> switching last-minute between "the same glob we use" and "the same glob
> used").
>
> Bringing it back to the example at hand, my assumption is that the
> bullet list capitalization and punctuation is mostly a question of
> style, and isn't making the result hard to understand. But if it is, I
> can try to adjust. I actually wrote a bulleted list in a commit message
> earlier today and capitalized it just for you. :)
Thanks for explaining!
Patrick
next prev parent reply other threads:[~2025-01-09 10:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 17:33 What's cooking in git.git (Dec 2024, #11; Mon, 30) Junio C Hamano
2024-12-31 17:27 ` René Scharfe
2025-01-03 7:39 ` Patrick Steinhardt
2025-01-01 19:14 ` a less-invasive racy-leak fix, was " Jeff King
2025-01-01 20:12 ` [PATCH 0/6] a less-invasive racy-leak fix Jeff King
2025-01-01 20:12 ` [PATCH 1/6] test-lib: use individual lsan dir for --stress runs Jeff King
2025-01-01 20:12 ` [PATCH 2/6] Revert "index-pack: spawn threads atomically" Jeff King
2025-01-01 20:14 ` [PATCH 3/6] test-lib: rely on logs to detect leaks Jeff King
2025-01-03 12:05 ` Patrick Steinhardt
2025-01-03 20:10 ` Jeff King
2025-01-01 20:17 ` [PATCH 4/6] test-lib: simplify leak-log checking Jeff King
2025-01-03 12:05 ` Patrick Steinhardt
2025-01-03 20:24 ` Jeff King
2025-01-06 7:56 ` Patrick Steinhardt
2025-01-07 7:01 ` Jeff King
2025-01-01 20:18 ` [PATCH 5/6] test-lib: check leak logs for presence of DEDUP_TOKEN Jeff King
2025-01-01 20:21 ` [PATCH 6/6] test-lib: ignore leaks in the sanitizer's thread code Jeff King
2025-01-03 12:05 ` Patrick Steinhardt
2025-01-03 20:26 ` Jeff King
2025-01-06 7:56 ` Patrick Steinhardt
2025-01-07 7:04 ` [PATCH 0/3] lsan test-lib readability Jeff King
2025-01-07 7:05 ` [PATCH 1/3] test-lib: invert return value of check_test_results_san_file_empty Jeff King
2025-01-07 7:07 ` [PATCH 2/3] test-lib: simplify lsan results check Jeff King
2025-01-07 7:37 ` Patrick Steinhardt
2025-01-09 7:57 ` Jeff King
2025-01-09 10:00 ` Patrick Steinhardt [this message]
2025-01-07 16:23 ` Junio C Hamano
2025-01-09 7:59 ` Jeff King
2025-01-07 7:08 ` [PATCH 3/3] test-lib: add a few comments to LSan log checking Jeff King
2025-01-07 7:37 ` Patrick Steinhardt
2025-01-02 0:25 ` a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30) Junio C Hamano
2025-01-02 2:32 ` Jeff King
2025-01-02 2:41 ` Chris Torek
2025-01-02 14:42 ` Junio C Hamano
2025-01-02 19:06 ` Jeff King
2025-01-02 19:33 ` Junio C Hamano
2025-01-02 3:24 ` Jeff King
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=Z3-eTDsHQ9Nu1er9@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.