> On 24 Oct 2025, at 2:48 am, Renee Otten <[email protected]> wrote:
>
>
>
>> On Oct 23, 2025, at 9:33 PM, Fred Wright <[email protected]> wrote:
>>
>>
>>> On Thu, 23 Oct 2025, Renee Otten wrote:
>>>
>>> (re-sending to list, this time using the correct e-mail account so the
>>> message doesn’t bounce)
>>
>> It didn't bounce here.
>
> It did as you can see on the archive, you got it initially as I did reply-all.
>
>
>>> I probably squash-merged the PRs and indeed I felt/feel that all the
>>> additional text in the commit message is superfluous.
>>
>> I see no reason to be stingy with commit messages when anyone who wants the
>> short-form view can just specify --oneline in the command. I never would
>> have gotten away with such short CL descriptions at Google.
>>
>> Commit messages complement code comments. The latter explain why the code
>> is the way it is; the former explain how it got there and why.
>>
>> It's been a long-standing tradition for Ruby updates to include a link to
>> the upstream release announcement; that was part of what was removed. I
>> only just yesterday determined the proper similar link for asciidoctor.
>>
>> Squashing isn't supposed to truncate commit messages anyway, though perhaps
>> GitHub has a weird interpretation. Squashing with the command-line tool
>> presents a concatenation of all the included commit messages, to be edited
>> into something appropriate for the combined commit. Though squashing a
>> single commit isn't even possible from the command line.
>
> What you do/did at Google is pretty much irrelevant here. A port update
> doesn’t need and extensive description, it’s just a version update. It’s
> great that you tested this on 20+ different systems, but IMO not really
> needed in a commit message. People who are interested in what changed in the
> new version can go the homepage, for example, with “port gohome <portname>”.
>
> AFAIK: the body of the commit message is for linking relevant Trac tickets,
> and adding some “minor” changes that don’t warrant an additional commit but
> don’t fit in the the summary either. That’s what I follow when committing
> things myself to the repository and when merging PRs.
Personally, when merging PRs if the author went to the effort of adding
additional information in the body of the commit messages I see no reason for
the maintainer committing it to just remove that information. I certainly would
never do that. As long as the summary line follows our guidelines, whatever
they choose to add after that is for me up to the commit author. I feel its
just a bit antagonistic to remove it for no reason.
>
> Renee
>
