From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1097 invoked by alias); 27 Dec 2019 13:29:28 -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 1088 invoked by uid 89); 27 Dec 2019 13:29:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Dec 2019 13:29:25 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id xBRDTJof011137; Fri, 27 Dec 2019 07:29:20 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xBRDTIG8011132; Fri, 27 Dec 2019 07:29:18 -0600 Date: Fri, 27 Dec 2019 13:29:00 -0000 From: Segher Boessenkool To: "Richard Earnshaw (lists)" Cc: Joseph Myers , Jakub Jelinek , Maxim Kuvyrkov , GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Mark Wielaard Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191227132918.GQ4505@gate.crashing.org> References: <20191225120747.GA96669@thyrsus.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <20191226183553.GK10088@tucnak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00447.txt.bz2 On Fri, Dec 27, 2019 at 11:21:41AM +0000, Richard Earnshaw (lists) wrote: > On 26/12/2019 18:59, Joseph Myers wrote: > > On Thu, 26 Dec 2019, Jakub Jelinek wrote: > >> 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. Archaeology is much simpler still if people do not do merges at all, but use a rebase (or rebase-like, e.g. quilt) workflow. That way, there are no bad changes that have to be undone later, etc. Ideally everything comes in as small, well thought out patches. Segher