From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107444 invoked by alias); 20 Dec 2019 16:28: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 107436 invoked by uid 89); 20 Dec 2019 16:28:47 -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=millions, H*f:sk:5ea5dd6, H*f:sk:fe11dcc, forthcoming 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, 20 Dec 2019 16:28:45 +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 xBKGSbhD006759; Fri, 20 Dec 2019 10:28:37 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xBKGSZQY006756; Fri, 20 Dec 2019 10:28:35 -0600 Date: Fri, 20 Dec 2019 16:28:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Joseph Myers , Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , gcc@gcc.gnu.org, esr@thyrsus.com Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191220162835.GF3152@gate.crashing.org> References: <0fb81074d87c96b3312565800b8bfc25cfcbe179.camel@redhat.com> <20191216215927.GG3152@gate.crashing.org> <20191216224244.GI3152@gate.crashing.org> <5ea5dd673eb006dd84af7e47fcbab53a15e8005d.camel@redhat.com> <20191218195043.GC3152@gate.crashing.org> 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/msg00367.txt.bz2 Hi! On Wed, Dec 18, 2019 at 01:43:19PM -0700, Jeff Law wrote: > 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? There is a lot more needed to write reliable programs than just domain knowledge. git-svn is used for this exact purpose (converting svn commits to git commits) millions of times per day, for I-don't-know- how long already. Yes, I trust that better than newly written code. The point is completely moot if we actually verify and compare the resulting trees, of course. > 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. Exactly the same here! But we need to look at the actual candidate conversions to determine this. Not just say "I like X better than Y". That is at best subjective; we can do better than that. > > > 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. And neither am I. I don't wait for things I do not expect to happen. And I want a Git conversion soon, not wait more years for it. > 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. This isn't a technical decision really. Both candidate conversions are perfect technically already (or will be soon). All that is left is a) aesthetics, so everyone wants something else; b) some people are dead set against falsifying history (including me), while other people think something that looks slightly better is more important; and c) what tags and branches do we not carry over from svn at all? We'll keep the svn repo around as well, anyway. If Joseph and Richard agree a candidate is good, then I will agree as well. All that can be left is nit-picking, and that is not worth it anyway: the repository will not be perfect no matter what, people have made mistakes, we can only fix some superficial ones. Some of those are practically important (because they are annoying), but most are not. Segher