This is the mail archive of the
mailing list for the GCC project.
Re: Commit messages and the move to git
On 05/11/2019 14:12, Marek Polacek wrote:
> On Tue, Nov 05, 2019 at 11:27:50AM +0000, Jason Merrill wrote:
>> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely <email@example.com> wrote:
>>> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
>>>> On Mon, 4 Nov 2019, Segher Boessenkool wrote:
>>>>> On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
>>>>>> I've already proposed a more specific format for libstdc++:
>>>>> PR libstdc++/12345 takes up the first 19 chars of the short subject,
>>>>> adding no useful information (unless the reader knows all PRs by heart,
>>>>> you need to look it up to know what it is).
>>>>> I usually put (PR12345) at the end of the subject. The area is clear
>>>>> from the rest of the subject already.
>>>> Agreed. (Hint to patch submitters: if the subject line of your patch
>>>> submission is just "Fix PR12345" or similar, people are less likely to
>>>> review your patch because nothing about the subject tells anyone that the
>>>> patch is in their area and so something they should pay attention to.
>>>> Patch submissions need to have subjects that make clear very quickly what
>>>> the patch is about. This is also why I don't care for [PATCH] tags at the
>>>> start of subject lines - they take away space for saying what the patch is
>>>> about, and on gcc-patches we can expect things are patches, [PATCH]
>>>> doesn't add useful information.)
>>> I don't mind [PATCH] in the subject of patch emails (maybe because
>>> nearly all my patches go to libstdc++@ as well, and not all mails on
>>> that list are patches), but it has negative value in the commit log.
>> I actively like [PATCH] in the subject line because I see patch mail
>> interleaved with other mail in my inbox.
>>> My mail to the libstdc++ list should have noted that [PATCH] tags in
>>> the email subject should be omitted from the summary in the first line
>>> of the commit log.
>> And git format-patch/git am automatically add and remove [PATCH] appropriately.
> Wrt [PATCH]: if we keep it, do we want to have a system to distinguish
> C/C++/... patches? Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH],
> something else? (I find the latter two a bit ugly.)
"git am --keep-non-patch" will strip sequences containing [.*PATCH.*]
(not a strict regexp, .* is anything other than ']'), and keep other
[.*] annotations. I don't know if this applies only up to the first
non-matching sequence, or at any point. See git-mailinfo's -b flag.
But my proposal (see post earlier) is that we should use <component>: in
the same way that libc (and, I understand, linux kernel folk) do.