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 <jwakely....@gmail.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++: >>>>>> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html >>>>> >>>>> 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. R. > Marek >
