From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80189 invoked by alias); 28 Dec 2019 12:19:30 -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 80181 invoked by uid 89); 28 Dec 2019 12:19:29 -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=stone, our, wish 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; Sat, 28 Dec 2019 12:19:28 +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 xBSCJNeR002356; Sat, 28 Dec 2019 06:19:23 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xBSCJLxs002352; Sat, 28 Dec 2019 06:19:21 -0600 Date: Sat, 28 Dec 2019 12:19:00 -0000 From: Segher Boessenkool To: Joseph Myers Cc: "Richard Earnshaw (lists)" , 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: <20191228121921.GW4505@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/msg00470.txt.bz2 On Fri, Dec 27, 2019 at 11:35:21AM +0000, Joseph Myers wrote: > On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote: > > > 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. > > To some extent it fits with the principle of separating changes to > workflow from the actual move to git (as the existing state is that we > have a linear history on trunk and the few merge properties that were > there were later deleted). So after the conversion we could consider if > for future merges we wish to use merge commits. SVN mergeinfo is not representable in Git. It records which changesets have been copied over from one branch to another. Git doesn't do changesets *at all*: it just stores tree contents, and it records one or multiple parents for every commit. That isn't actually derivable from the SVN info. You can guess, and you can guess wrong. Branch merges do not mesh well with our commit policies, fwiw: everything should normally be posted for public review on the mailing lists. This does not really work for commits that have been set in stone months before. Segher