From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107210 invoked by alias); 27 Dec 2019 11:21:47 -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 107201 invoked by uid 89); 27 Dec 2019 11:21:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Dec 2019 11:21:45 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D9831FB; Fri, 27 Dec 2019 03:21:44 -0800 (PST) Received: from [192.168.1.2] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9FF333F6CF; Fri, 27 Dec 2019 03:21:42 -0800 (PST) Subject: Re: Proposal for the transition timetable for the move to GIT To: Joseph Myers , Jakub Jelinek Cc: Maxim Kuvyrkov , GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard References: <20191216153649.GE3152@gate.crashing.org> <20191225120747.GA96669@thyrsus.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <20191226183553.GK10088@tucnak> From: "Richard Earnshaw (lists)" Message-ID: Date: Fri, 27 Dec 2019 11:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-12/txt/msg00441.txt.bz2 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. R.