From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123524 invoked by alias); 18 Dec 2019 20:43:29 -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 123515 invoked by uid 89); 18 Dec 2019 20:43:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=ours, CVS, highlights X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2019 20:43:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576701806; 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=tBhCtL19it5XKKTq2mI7fQ3Ypi8puZO5oD7FZToV8t8=; b=LGwpb56r/mhTWlaY6yrhfXx1pIg2MGLB8CVSezkXUc+ziiiM94uoptj3kuIGUCw2bUNaNZ pndcx6JKy6Zg4kHazf/vEfUs4pITCMoGxNGuQIec0PcYj7p0EnUcxMKvZqaDZyCc0ySqad h06OIkBngngnMYMvFzc87TTXvftEN4M= 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-47-cEVKoKqlOGKQket5aFmx8w-1; Wed, 18 Dec 2019 15:43:23 -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 4F361800D48; Wed, 18 Dec 2019 20:43:21 +0000 (UTC) Received: from ovpn-112-28.phx2.redhat.com (ovpn-112-28.phx2.redhat.com [10.3.112.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 175C410013A1; Wed, 18 Dec 2019 20:43:19 +0000 (UTC) Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT From: Jeff Law Reply-To: law@redhat.com To: Segher Boessenkool Cc: Joseph Myers , Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , gcc@gcc.gnu.org, esr@thyrsus.com Date: Wed, 18 Dec 2019 20:43:00 -0000 In-Reply-To: <20191218195043.GC3152@gate.crashing.org> References: <9E009921-96EA-44A2-A06A-232711227E69@linaro.org> <0fb81074d87c96b3312565800b8bfc25cfcbe179.camel@redhat.com> <20191216215927.GG3152@gate.crashing.org> <20191216224244.GI3152@gate.crashing.org> <5ea5dd673eb006dd84af7e47fcbab53a15e8005d.camel@redhat.com> <20191218195043.GC3152@gate.crashing.org> User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00287.txt.bz2 On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote: > On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote: > > > That isn't what I said. I said that freshly constructed complex software > > > will have more and deeper errors than stupid simple scripts do (or I > > > implied that at least, maybe it wasn't clear). And I only say this > > > because the opposite was claimed, which is laughable imnsho. > > But it's not that freshly constructed, at least not in my mind. All > > the experience ESR has from the python implementation carries to the Go > > implementation. > > What, writing code in Python made him learn Go? ?!? What does that question have to do with anything? My point is the experience of writing reposurgeon and in particular being intimately familiar with what does on under the hood inside CVS, SVN and GIT has great value, particularly in converting a large repo like ours that has warts from the CVS and SVN days as well as warts from the CVS->SVN conversion. > > And the "simple scripts" argument dismisses the fact that those scripts > > are built on top of complex software. It just doesn't hold water IMHO. > > This is the Unix philosophy though! But your comment doesn't address the fact that in both cases, reposurgeon and Maxim's scripts, there's complex code involved. In Maxim's case it's just under the covers. Ultimately I don't care about the Unix philosophy. I'm pragmatic. If reposurgeon gives us a better conversion, and it sounds very much like it already does, then the fact that it doesn't follow the Unix philosophy is irrelevant to me. > > > Where I think we could have done better would have been to get more > > concrete detail from ESR about the problems with git-svn. That was > > never forthcoming and it's a disappointment. > > Yes. And as far as I can see you can wait forever for it. Oh well, we > have a lot of experience in waiting. Umm, no, I'm not suggesting we wait in any way at all. Based on what I've heard from Joseph, I'd vote today to go with reposurgeon as soon as it's convenient for the people doing the conversion and our development cycle. This highlights one big issue that we have as a project. Specifically that we don't have a clear cut way to make these kinds of technical decisions when there isn't unanimous consent. > > > I do think we've gotten some details about the "scar tissue" from the > > cvs->svn transition as well as some of our branch problems. It's my > > understanding reposurgeon cleans this up significantly whereas Maxim's > > scripts don't touch this stuff IIUC. > > They do, I think? This was easy to do, too: > git://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/ Good. Thanks for clarifying. > > > > > > As long as the original commit message is kept, verbatim, and you only > > > > > add a new summary line, all is fine. If not -> nope, not okay. > > > > Sorry, have to disagree here. I think what Richard has done is a > > > > significant step forward. > > > > > > We talked about it for days, and as far as I understand it Richard agreed. > > When Richard and I spoke we generally agreed that we felt a reposurgeon > > conversion, if it could be made to work was the preferred solution, > > followed by Maxim's approach and lastly the existing git-svn mirror. > > If I'm mis-representing Richard's position I hope he'll chime in and > > correct the record. > > This is just about the "we should not try to change the commit message", > and Joseph confirmed that is what is done now. So that is all fine. OK jeff