From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 069BE3857C4C for ; Fri, 7 Jan 2022 10:51:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 069BE3857C4C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-549-a0wSn4GEOMqPO7e9U7lSuA-1; Fri, 07 Jan 2022 05:51:38 -0500 X-MC-Unique: a0wSn4GEOMqPO7e9U7lSuA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6AEC11006AA5; Fri, 7 Jan 2022 10:51:37 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.2.16.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0A82522DEE; Fri, 7 Jan 2022 10:51:36 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 207ApYaG2538649 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 7 Jan 2022 11:51:34 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 207ApXiA2538648; Fri, 7 Jan 2022 11:51:33 +0100 Date: Fri, 7 Jan 2022 11:51:33 +0100 From: Jakub Jelinek To: Martin Jambor Cc: GCC Mailing List Subject: Re: Mass rename of C++ .c files to .cc suffix? Message-ID: <20220107105133.GH2646553@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Fri, 07 Jan 2022 10:51:43 -0000 On Fri, Jan 07, 2022 at 11:25:50AM +0100, Martin Jambor wrote: > Would anyone be terribly against mass renaming all *.c files (that are > actually C++ files) within the gcc subdirectory to ones with .cc suffix? > > We already have 47 files with suffix .cc directly in the gcc > subdirectory and 160 if we also count those in (non-testsuite) > subdirectories, while the majority of our non-header C++ files still has > the .c suffix. > > I have already missed stuff when grepping because I did not include *.cc > files and the inconsistency is also just ugly and must be very confusing > to anyone who encounters it for the first time. > > Since we have switched to git, this should have quite small effect on > anyone who does their development on branches. With Martin Liška we did > a few experiments and git blame, git rebase and even git gcc-backport > worked seamlessly across a rename. > > I would be fine waiting with it until GCC 12 gets released but see > little value in doing so. > > What do others think? (Any important caveats I might have missed?) 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? Jakub