Re: [PATCH v5 2/4] docs: improve formatting in git-send-email documentation
From: Aditya Garg <hidden>
Date: 2025-05-30 14:51:50
On 30 May 2025, at 8:18 PM, Ben Knoble [off-list ref] wrote: quoted
Le 30 mai 2025 à 09:28, Junio C Hamano [off-list ref] a écrit : Aditya Garg [off-list ref] writes:quoted
quoted
quoted
-When `--compose` is used, git send-email will use the From, To, Cc, Bcc, -Subject, Reply-To, and In-Reply-To headers specified in the message. If -the body of the message (what you type after the headers and a blank -line) only contains blank (or Git: prefixed) lines, the summary won't be +When `--compose` is used, `git send-email` will use the 'From', 'To', 'Cc', +'Bcc', 'Subject', 'Reply-To', and 'In-Reply-To' headers specified in the +message. If the body of the message (what you type after the headers and a +blank line) only contains blank (or Git: prefixed) lines, the summary won't beShouldn't 'Git:' in "or Git: prefixed" be marked-up somehow as well? As these mail header names are all literal parts, shouldn't ehy be marked up like `To`, `Cc`, etc.?I think its ok to let these remain in '', and deviate from the rules a bit. If backticks are used, it will be a mess when rendered on the website.I do not think I agree; bending the rule only because the density of literals in a single paragraph is too heavy does not sound like a good application of a rule---it is hard to justify such an exception.To go a bit further, rendered HTML is also not the only output format, though I don’t think the markup here affects manual pages substantially? So using « the website » (which? presumably git-scm.com) as justification prioritizes the look of one output format over other concerns, no? For plaintext viewing, consistency is probably helpful.
Ok I'll send another revision.