From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 5F6863838025 for ; Thu, 8 Jul 2021 08:26:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F6863838025 Received: by mail-wr1-x42c.google.com with SMTP id q17so6425761wrv.2 for ; Thu, 08 Jul 2021 01:26:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r0rAh2lKJQDn90AbptFT1B4tl1r/8m+oZth7sxo1fm0=; b=kigffkSeJfVjHIvU/GHEJaIoTwGk0LMX8EOxuR6laIrw/r4lGTZmj9GB4jGPyqit8p qZIWVKC3yZlHcw7wsgQU2pkiAFcdrM6DP673+X0xDvAXuGZPZ6TpZhDZkBt9fyirXYXp FlolaVPdaAT+JXS3wFZVi1jm3CAYj56YplcAgeeIztEOtZz6KrPxrcc8H0kZEYuDBwaA DJOgapXVnaK/WTNAL0I2QJs9M6AqabCTdAX14ukcnY5/zPauYDU0aEkPEPhLPPeBm5M2 CSClm0iDzD9hYbbQndDHmFrhFd7Fj43EBQZjel5adXfccy21xIlfpfB9zGMEl68rx0zD 8dzg== X-Gm-Message-State: AOAM532nMe7KrdwAXOjv54BR/7q0oEfzEwM/XSrdkuYkZVOFgC9Mi4tf DmVFGB4xX3dzI0FBMW8GUb9vp+7P+wlp5iCj2rg= X-Google-Smtp-Source: ABdhPJxMr1hY1jY3bipcHHRYl/Uf4uPCWejCLfFvMJxvb3yewKoQ7MijNHihlyLYnRy+G57kQ09AL5/ofFhahcCVQew= X-Received: by 2002:adf:a74a:: with SMTP id e10mr32613690wrd.185.1625732803511; Thu, 08 Jul 2021 01:26:43 -0700 (PDT) MIME-Version: 1.0 References: <9121724e-e741-9bad-a39d-d6ac49422589@gmail.com> <734e36bd-5adb-feed-7e89-d63d233198a4@gmail.com> <4be7bb29-c830-05b9-99e5-7e54966d4b5c@gmail.com> In-Reply-To: <4be7bb29-c830-05b9-99e5-7e54966d4b5c@gmail.com> From: Jonathan Wakely Date: Thu, 8 Jul 2021 09:26:32 +0100 Message-ID: Subject: Re: where is PRnnnn required again? To: Martin Sebor Cc: Marek Polacek , gcc mailing list X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, FREEMAIL_REPLY, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 08:26:45 -0000 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.