From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118410 invoked by alias); 27 Dec 2019 11:33:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 118399 invoked by uid 89); 27 Dec 2019 11:33:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=helped, H*f:sk:d9a8603, H*i:sk:d9a8603 X-HELO: mail-ua1-f42.google.com Received: from mail-ua1-f42.google.com (HELO mail-ua1-f42.google.com) (209.85.222.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Dec 2019 11:33:10 +0000 Received: by mail-ua1-f42.google.com with SMTP id z24so3575982uam.7 for ; Fri, 27 Dec 2019 03:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7iI3YLzQSY3V0GRdmsOZZ1NckPRc+JQln4UHpY8H0Hw=; b=bdE2n71EsaLlqIGZSKM4pgEffJqDr3pLx6RSeIHipEN8PMtTlGoWgq6ZKmM9EjDjFV 5+ebmNewsarVdc8xcMFSKqeo8+1U2ItsOBTDtUaLP16iA+HjKpfPi9QrZsCNNmhNxE/e BCa42si/BmbE/QgLZb9fSHCY1iFJO/xJJh88mAxK+3CtGAUQ5GmJADZjeAn6HNBjfSM8 ZYeT/AmBpB/L1mcuHWr6LMS9Qz5ckYkiz/1zlj6rufkdyz7RYUE9t6AO6UZp6HpWsCZE WRnJBME4/qQRHgkF1uJ+1pKKV757CFy0yVU5QCYnpLPc5P/+dxJDI1gnAdOBfgrACCcn 9sCw== MIME-Version: 1.0 References: <20191216153649.GE3152@gate.crashing.org> <20191225120747.GA96669@thyrsus.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <20191226183553.GK10088@tucnak> In-Reply-To: From: Andrew Pinski Date: Fri, 27 Dec 2019 11:33:00 -0000 Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT To: "Richard Earnshaw (lists)" Cc: Joseph Myers , Jakub Jelinek , Maxim Kuvyrkov , GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00442.txt.bz2 On Fri, Dec 27, 2019 at 3:22 AM Richard Earnshaw (lists) wrote: > > On 26/12/2019 18:59, Joseph Myers wrote: > > On Thu, 26 Dec 2019, Jakub Jelinek wrote: > > > >> On Thu, Dec 26, 2019 at 04:58:22PM +0000, Joseph Myers wrote: > >>> If we don't want merge commits on git master for the cases where people > >>> put merge properties on trunk in the past, we can use a reposurgeon > >>> "unmerge" command in gcc.lift to stop the few commits in question from > >>> being merge commits (while keeping all other merges as-is). (The merges > >>> of trunk into other branches that copied merge properties from trunk into > >>> those branches will still be handled correctly, with exactly two parents > >>> rather than regaining the extra parents corresponding to the merges into > >>> trunk that Bernd noted in an earlier version of the conversion, because > >>> the processing that avoids redundant merge parents takes place well before > >>> any unmerge commands are executed - so at the time of that processing, > >>> reposurgeon knows that those other branches are in fact in the ancestry of > >>> trunk, even if we remove that information in the final git repository.) > >> > >> Yes, I'd prefer the trunk to have no merge commits (in svn I've removed the > >> svn:mergeinfo property on the trunk when it appeared too). > > > > I've added the unmerge commands for the three commits in question to > > gcc.lift. > > > > I'm not really sure I understand why we don't want merge commits into > trunk, especially for large changes. Performing archaeology on a change > is just so much easier if the development history is just there. > > Without the merge information, if you're tracking down the reason for a > bug, you get to the merge, and then have to go find the branch where the > development was done and start the process all over again. With merge > information, tools like git blame will show which commit during > development touched the relevant line last and a major step in analysis > is vastly simplified. The one branch merge which would have helped me track down why a testcase was added is the tree-ssa branch merge. If we had the commit for the merge to have the merge info, it would have been easier for me to track down that. Note this testcase failed with a new patch I am working on and I decided in the end, the testcase is bogus and not even testing what it was testing for anyways. There is a few other instances like that which would have been helpful. Thanks, Andrew Pinski > > R.