Re: where is PRnnnn required again?

[Martin Sebor <msebor@gmail.com>]

On 7/8/21 2:26 AM, Jonathan Wakely wrote:
> 
> 
> On Wed, 7 Jul 2021, 23:58 Martin Sebor, <msebor@gmail.com 
> <mailto:msebor@gmail.com>> wrote:
> 
>     On 7/7/21 4:24 PM, Jonathan Wakely wrote:
>      >
>      >
>      > On Wed, 7 Jul 2021, 23:18 Martin Sebor, <msebor@gmail.com
>     <mailto:msebor@gmail.com>
>      > <mailto:msebor@gmail.com <mailto:msebor@gmail.com>>> wrote:
>      >
>      >     On 7/7/21 3:53 PM, Marek Polacek wrote:
>      >      > I'm not sure why you keep hitting so many issues; git addlog
>      >     takes care of
>      >      > this stuff for me and I've had no trouble pushing my
>     patches.  Is
>      >     there
>      >      > a reason you don't use it also?
>      >
>      >     I probably have a completely different workflow.  Git addlog
>     isn't
>      >     a git command (is it some sort of a GCC extension?), and what
>     I put
>      >     in the subject of my emails is almost never the same thing as
>     what
>      >     I put in the commit message.
>      >
>      >
>      > Why not? Why is it useful to write two different explanations of
>     the patch?
> 
>     Sometimes, maybe.  I don't really think about it too much.  I'm not
>     the only one who does it.  But what bearing does what we put in
>     the subject of our patch submissions have on this discussion?
> 
> 
> 
> My failed attempt to clarify the docs on commit message formats 
> recommended using the same text for the commit message and email. If 
> there's a good reason to deviate from that, I'd like to know. Not that I 
> plan to change those docs again, it was a waste of time.
> 
> Also, you're proposing that PR numbers don't need to be in the subject 
> and/or that if it's in the subject it doesn't need to be in the body. Is 
> it just because "it's inconvenient for my current workflow" ? If it's in 
> the subject of the patch, why wouldn't you put it in the email subject too?
> 
> If writing two different descriptions of the patch by hand is liable to 
> not meet the formatting conventions, it seems like using existing 
> automation for creating the message (and reusing it for the email) might 
> be worth trying.
> 
> That doesn't mean we can't also improve the convention.

I'm sure different people do things differently but since you ask:
I use mklog.py with the -p option to create the commit message and
paste it into the patch.  Sometimes I use the long
"PR component/nnnn - bug description" as the title of the patch.
This is a force of habit from pre-Git days when there was no
convention or encouragement what to use (AFAIK).  I'll probably
get used to the new and improved way of doing things over time
but I'm not there yet.  I then use Thunderbird to compose an email
with the patch attached to it and I come up with a subject for
the email.  If I don't think of the new convention it may be
different from what's already in the patch.

I'm all for conventions and best practices but when tooling can
easily adjust things into the desired shape I think it should be
preferred to smacking people upside the head each time the don't
get everything just right.  And sometimes, taking a convention
as a guideline rather than a strict mandate is also fine (say
the 35 or 50 or 75 character limit for the subject of an email
or title of a patch).

Martin