From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by sourceware.org (Postfix) with ESMTPS id 4DF7C383D00B for ; Thu, 8 Jul 2021 18:58:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DF7C383D00B Received: by mail-qt1-x832.google.com with SMTP id n9so5655943qtk.7 for ; Thu, 08 Jul 2021 11:58:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/V+0XUXCJW30cpOTqBEo6G/9xcgSw5hFBT7DNoMmlJM=; b=OQf5Y5hTpXhTm0JFQxKfz5Sx5XFxVRapFIowyPieAjPrpa+lFXyFd1xbgGfDnPIO4e 0RO7YgRruSJa+S/P2WWR1F7WSvqcFzD2Hfxu3JiZCIJSeqEUr1BRw7RFy/d5v/J9aP+w TqDeW/gfeytN5D+oK+p6kSu/dGZo85qgFtk8kUdkUrL3s/tiPGewwZl7pEElS9IbthP9 9NG6JvJNW724uVP3IyWgUbVfMSP8lopWVchzhrCgZHC2cC0rYymfd1zgPfJhF/RtwZXf JlZDPDVouWu2lkI//duKpJ9x1nQK8KxH/UTXqZXljbCUxzZG4ILNszSpYOhieJXGGyeI Y3yg== X-Gm-Message-State: AOAM531xSbYiNlIPDfLskRkLshrMYf9FSlXz6Q3VSnElGQNSOhtidr+g 94F1aGO7HgbJ9KwoFvwT7QNhvrPwIW0= X-Google-Smtp-Source: ABdhPJw9B5fCSBbQhpjNFs9QMLKoz5gscY8M2SRRqTAuqV39Rxc/GInyoOyVmwM84QUi9Uttvotrlw== X-Received: by 2002:a05:622a:13d1:: with SMTP id p17mr29697182qtk.215.1625770689575; Thu, 08 Jul 2021 11:58:09 -0700 (PDT) Received: from [192.168.0.41] (75-166-102-22.hlrn.qwest.net. [75.166.102.22]) by smtp.gmail.com with ESMTPSA id 5sm1268604qtb.22.2021.07.08.11.58.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jul 2021 11:58:08 -0700 (PDT) Subject: Re: where is PRnnnn required again? To: Jonathan Wakely Cc: Marek Polacek , gcc mailing list References: <9121724e-e741-9bad-a39d-d6ac49422589@gmail.com> <734e36bd-5adb-feed-7e89-d63d233198a4@gmail.com> <4be7bb29-c830-05b9-99e5-7e54966d4b5c@gmail.com> From: Martin Sebor Message-ID: <0c9e3a28-9750-7f43-c6d0-2167c24c276e@gmail.com> Date: Thu, 8 Jul 2021 12:58:07 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 18:58:11 -0000 On 7/8/21 2:26 AM, Jonathan Wakely wrote: > > > On Wed, 7 Jul 2021, 23:58 Martin Sebor, > wrote: > > On 7/7/21 4:24 PM, Jonathan Wakely wrote: > > > > > > On Wed, 7 Jul 2021, 23:18 Martin Sebor, > > >> 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