From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40887 invoked by alias); 26 Dec 2019 18:36:10 -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 40877 invoked by uid 89); 26 Dec 2019 18:36:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1161 X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Dec 2019 18:36:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1577385367; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sWISpNHUDMOBrCa0E4jLEOaRI02Yv9FTqVeGlbLrgVs=; b=OvPnKYZ+zxqFYkxNvnneHv6O7gIFLHVRC4i5BY+hJLbc8I55T3wyd20lZ2cam1OPkBUV+W 8JaxsHqFxK9RG9lCE/GYRVWUtcgITtmmuyNl4VywaRyv9h2WeFP1c4o4owrr3V0ORaRp6V 2+CwfmPs/dimsW3TgHdFyLGekJE4svw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-zmyR3a2kNoau4hUFHe4IaQ-1; Thu, 26 Dec 2019 13:36:02 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 98E70800D55; Thu, 26 Dec 2019 18:36:00 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-112.ams2.redhat.com [10.36.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78392100EBA4; Thu, 26 Dec 2019 18:35:59 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id xBQIZu1n009644; Thu, 26 Dec 2019 19:35:56 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id xBQIZrq0009643; Thu, 26 Dec 2019 19:35:53 +0100 Date: Thu, 26 Dec 2019 18:36:00 -0000 From: Jakub Jelinek To: Joseph Myers Cc: Maxim Kuvyrkov , GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard , "Richard Earnshaw (lists)" Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191226183553.GK10088@tucnak> Reply-To: Jakub Jelinek References: <20191216153649.GE3152@gate.crashing.org> <20191225120747.GA96669@thyrsus.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00424.txt.bz2 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=20 > put merge properties on trunk in the past, we can use a reposurgeon=20 > "unmerge" command in gcc.lift to stop the few commits in question from=20 > being merge commits (while keeping all other merges as-is). (The merges= =20 > of trunk into other branches that copied merge properties from trunk into= =20 > those branches will still be handled correctly, with exactly two parents= =20 > rather than regaining the extra parents corresponding to the merges into= =20 > trunk that Bernd noted in an earlier version of the conversion, because=20 > the processing that avoids redundant merge parents takes place well befor= e=20 > any unmerge commands are executed - so at the time of that processing,=20 > reposurgeon knows that those other branches are in fact in the ancestry o= f=20 > 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). Jakub