From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely.gcc@gmail.com>
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [IPv6:2a00:1450:4864:20::435])
 by sourceware.org (Postfix) with ESMTPS id 7C5C53858413
 for <gcc@gcc.gnu.org>; Fri,  7 Jan 2022 11:05:42 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C5C53858413
Received: by mail-wr1-x435.google.com with SMTP id l10so10363953wrh.7
 for <gcc@gcc.gnu.org>; Fri, 07 Jan 2022 03:05:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=iU06SC3UbOSKuuvrd7j7O6Z4/FfcgpYiD/z9WamohK0=;
 b=Rl9J9pf8bFXNZHHAqmh5Y9Cq1xbsgVhIecAldW2rOFhxkZKmQfDDRS06y4HH8Q7T2R
 rP1wzQsXz4PKi826q+uu1seL0vXh9QrHv9jOgyPrwujxQlKmJM9p7EHUl80G8/04TQwa
 +C8dxAPzX0c08wwUjXU4Poj4LvjG5IQ+wldC6QokYiZ9cvxeP86+KAPMRAWtbgX0qdeM
 R+pGObJo+Cb0GA89k0VpnYP/Mv+YD2VC3iFbUjKG2GgAwTuJaeImKqY+S9kt/pkh0SwZ
 RYcdaRk+t3JWDjzWYQ5//zV2uS2L5O3yurJOlN7ZW7UtF19mD/7voTvRb1IxAAsxk9Go
 0bRA==
X-Gm-Message-State: AOAM531qWePqzTtB/6Cx3VFlbBIzSdKA+cpeRIwrzBatZO4PMieR81B1
 CgdNqzrtpgqNivaS+AcaiwwtTi7P9MMvpUerp+0=
X-Google-Smtp-Source: ABdhPJxzCg8U1+AuDgZDKGzn61/lIUe7aFjKBWhHw5n8ZR4MMHtUjs3kaLBOt+Kw20XHiaAfCP7Wpp/PDHetdEIWAx4=
X-Received: by 2002:adf:dec9:: with SMTP id i9mr6841389wrn.221.1641553541598; 
 Fri, 07 Jan 2022 03:05:41 -0800 (PST)
MIME-Version: 1.0
References: <ri6mtk7vo41.fsf@suse.cz> <20220107105133.GH2646553@tucnak>
In-Reply-To: <20220107105133.GH2646553@tucnak>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Fri, 7 Jan 2022 11:05:30 +0000
Message-ID: <CAH6eHdRB6md9jSL1-MvGzu6dKQpsj7fj=7T+GiGzy5Txn8Zgtw@mail.gmail.com>
Subject: Re: Mass rename of C++ .c files to .cc suffix?
To: Jakub Jelinek <jakub@redhat.com>
Cc: Martin Jambor <mjambor@suse.cz>, GCC Mailing List <gcc@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2022 11:05:46 -0000

On Fri, 7 Jan 2022 at 10:54, Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
> My big worry would be backporting for the next 2 years.
> Do we need to adjust commit messages when backporting to replace *.cc with
> *.c in there?  Does git cherry-pick handle the changed files or do we
> need to resolve conflicts manually?

git cherry-pick (and the gcc-backport alias) should handle it
automatically, unless the diffs between trunk and the branch are a
large percentage of the whole file. IOf a file has been renamed then
Git finds the file to apply the patch to by comparing file contents
fuzzily. For a large repo like GCC you might want to set the
merge.renameLimit config variable so that it doesn't give up trying to
find the file too early. I did 'git config merge.renameLimit 9001' in
my repos. You can also set it to 0 which uses a hardcoded maximum
decided by Git, which gets updated now and then to ensure it works for
the kernel. That maps to a value much larger than 9000, but I've found
that my GCC cherry picks work with 9001.

References to .cc files in the commit message won't get changed to .c
automatically, but maybe the gcc-backport alias could be taught to do
that.