From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <macro@linux-mips.org>
Received: from cvs.linux-mips.org (eddie.linux-mips.org [148.251.95.138])
 by sourceware.org (Postfix) with ESMTP id CC45A385DC09
 for <gcc-patches@gcc.gnu.org>; Wed,  1 Apr 2020 10:05:01 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CC45A385DC09
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=linux-mips.org
Authentication-Results: sourceware.org;
 spf=none smtp.mailfrom=macro@linux-mips.org
Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org
 with ESMTP id S23992512AbgDAKE6GT1aW (ORCPT
 <rfc822;gcc-patches@gcc.gnu.org>); Wed, 1 Apr 2020 12:04:58 +0200
Date: Wed, 1 Apr 2020 11:04:58 +0100 (BST)
Sender: "Maciej W. Rozycki" <macro@linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: =?UTF-8?Q?Martin_Li=C5=A1ka?= <mliska@suse.cz>
cc: Jakub Jelinek <jakub@redhat.com>,
 GCC Patches <gcc-patches@gcc.gnu.org>, binutils@sourceware.org,
 "H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: [PATCH] PR lto/94249: Correct endianness detection with the
 __BYTE_ORDER macro
In-Reply-To: <58a785c1-08fc-a491-e19d-2b42e0a9817b@suse.cz>
Message-ID: <alpine.LFD.2.21.2004011101110.3939520@eddie.linux-mips.org>
References: <20200323103505.GF2156@tucnak>
 <6313e487-6dbb-ac17-4160-4ac600af40be@suse.cz>
 <7369b1aa-be0d-92cc-4f81-1612f101e2e8@suse.cz>
 <CAFiYyc3yKQpWzh3Yzh7b40adi=gtFmYLeEZex_yCqYGSOdFcEw@mail.gmail.com>
 <CAMe9rOqQf+3wO2rosK-jCNYEqc3e-OMP3NtVH0EX26aKGaFeBg@mail.gmail.com>
 <3786da05-1530-38c5-e9e2-cd69418cd42a@suse.cz>
 <CAMe9rOpFyGpzQwqsmz0ikZz3MhY4FsZYv_+jCNAHq0768vPw5Q@mail.gmail.com>
 <5b27738a-9885-9906-0c93-888daf4a066f@suse.cz> <20200324083109.GP2156@tucnak>
 <e96704f3-9025-48af-f894-81401a5718a4@suse.cz>
 <20200324091805.GQ2156@tucnak> <b5a25c37-d29c-b636-04ef-eba959ad495b@suse.cz>
 <alpine.LFD.2.21.2003301906260.2689954@eddie.linux-mips.org>
 <58a785c1-08fc-a491-e19d-2b42e0a9817b@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP,
 UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 10:05:02 -0000

On Wed, 1 Apr 2020, Martin Liška wrote:

> >   NB if posting as an attachment please try matching the message subject
> > with the change heading as otherwise it takes a lot of effort to track the
> > patch submission corresponding to a given commit.
> 
> I see your point, but note that sometimes a direction of a patch changes
> during
> the mailing list discussion. And so that we end up with a commit message that
> has a different name.

 What's the problem with changing the message subject at the point the 
final change is posted, just as I did with the change I submitted (where 
you chose to actually ignore what I posted and gratuitously changed the 
commit heading from one I used anyway)?

  Maciej