From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101478 invoked by alias); 29 Dec 2019 13:48:40 -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 101450 invoked by uid 89); 29 Dec 2019 13:48:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=techniques, harmful, extensively, productivity X-HELO: smtp1-g21.free.fr Received: from smtp1-g21.free.fr (HELO smtp1-g21.free.fr) (212.27.42.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 13:48:37 +0000 Received: from [IPv6:2a01:cb14:b74:a500:c65:2afb:4db2:7170] (unknown [IPv6:2a01:cb14:b74:a500:c65:2afb:4db2:7170]) (Authenticated sender: frnchfrgg) by smtp1-g21.free.fr (Postfix) with ESMTPSA id 7BFE8B00573; Sun, 29 Dec 2019 14:48:31 +0100 (CET) Subject: Re: Proposal for the transition timetable for the move to GIT To: Segher Boessenkool Cc: gcc@gcc.gnu.org References: <20191226183553.GK10088@tucnak> <20191228121921.GW4505@gate.crashing.org> <20191228202824.GZ4505@gate.crashing.org> <20191229104100.GA3191@gate.crashing.org> <98729b61-2322-4244-7bde-f29c7e654d59@free.fr> <20191229132649.GC3191@gate.crashing.org> From: Julien '_FrnchFrgg_' RIVAUD Message-ID: Date: Sun, 29 Dec 2019 13:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191229132649.GC3191@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-12/txt/msg00503.txt.bz2 Le 29/12/2019 à 14:26, Segher Boessenkool a écrit : > Hi! > > On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: >> I'm not arguing that you should go that route, it seems a bit extreme to >> me. But outright refusing merges on the basis they are painful is (if >> you can accept the strong word) ludicrous. > They are painful for everyone working with the history later. I don't think merges make looking at history more or less painful, unless you consider projects like git where there are a inordinate amount of merges. And even then, I think they have solutions. > Something that we do in GCC more often than in most other projects. I would have expected a lot if not all projects to look often in history, at least for projects with significant complexity. > > Which is almost *never* the case for GCC, in my opinion. Almost all > commits are smallish improvements / bugfixes. Which are indepenent, clearly. > Every patch should normally be posted to the mailing lists for review. > Such patches should be against trunk. And *that* patch will be approved, > so *that* is the one you will commit and push upstream eventually. Indeed, the rebased series would be what is reviewed and pushed upstream. Which can be done with a merge commit anyway. I think you really should look at the workflow of the git project (and they have their share of interdependent strange things that happen too; of course less than GCC due to the complexity of the project, but the techniques to ensure you don't get bitten by that are the same). They use merges extensively, and have a very very good track record of non-broken master (or at least had last time I looked). > > We cannot waste a year on a social experiment. We can slowly and carefully > adopt new procedures, certainly. But anything drastic isn't advisable imo. > > Also, many GCC developers aren't familiar with Git at all. It takes time > to learn it, and to learn new ways of working. Small steps are needed. Of course ! I am not suggesting you change everything. But setting in stone hard rules that force the SVN mindset is harmful too. > Merges aren't scary. Merges are inconvenient. No they are not. You are unaccustomed to them, which is different. People that only ever used DVCS feel merges are much more natural and even productivity increasing. Some even do "bad merges", like "sync from trunk" every other commit, which I very much frown against. Which brings me to something I find strange in your policy: to me, merges from trunk to branches should be rare if not nonexistent. And you are deciding to banish merges the other way around. Julien