On Tue, 2019-11-05 at 11:27 +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.
FWIW my convention has been to put "[PATCH]" in the email subject line for patches I want reviewed, and "[committed]" for patches that I've already self-approved (or are obvious) and thus don't need review. +1 from me on making commit messages have git-friendly summary lines (I've been doing this myself since shortly after I joined gcc). I'm not too bothered about the precise format FWIW - maybe it's better not to be too prescriptive about the format, beyond "make them concise, and useful for you and your fellow maintainers"? I try to use the same message as the email subject line, to make cross-referencing between the mailing list and source repos easier when doing "archaeology". (that said, keeping "[PATCH]" in the *commit* message is a pet peeve of mine, as it's redundant). I also tend to put in the "blurb" from the email into the commit message, especially if it's a pertinent high-level description of the purpose of the *change* (as opposed to a description of the *code*, which should live in a comment in the code, rather than the metadata). > > 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. > > I tend to put the PR number at the beginning of the line, but I don't > object to putting it at the end instead. > > Jason >
