On 21/01/2020 17:20, Jason Merrill wrote:
On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
On 21/01/2020 15:39, Jakub Jelinek wrote:
On Tue, Jan 21, 2020 at 03:33:22PM +0000, Richard Earnshaw (lists)
wrote:
Some examples would be useful I'd say, e.g. it is unclear in what
way you
want the PR number to be appended, shall it be
something: whatever words describe it PR12345
or
something: whatever words describe it (PR12345)
or
something: whatever words describe it: PR12345
or
something: whatever words describe it [PR12345]
or something else?
Glibc use "[BZ #nnnn]" - obviously BZ becomes PR, but after that,
I'm not
too worried. I'd be happy with [PR #nnnn], but if folk want
something else,
please say so quickly...
[PR 12345] or [PR #12345] is bad, because the bugzilla won't
underline it,
it needs to be either PR12345 word, or PR component/12345 .
ok, lets go with [PRnnnn] then.
Doesn't this use of [] have the same problem with git am?
No, because only 'leading' [] blocks are removed - git mailinfo --help
My summaries are often describing the bug I'm fixing, i.e.
[PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.
which is also the first line of my ChangeLog entry. I think you are
proposing
[COMMITTED] c++: Fix anon-namespace reference temp clash between TUs
(PR91476)
which can no longer be shared with the ChangeLog.
I was trying to unify this with glibc. They specify the bug number at
the end of the line.
We can diverge if it's generally felt to be important, but details like
this create needless friction for folk working in both communities.
R.