From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21956 invoked by alias); 30 Dec 2019 00:31:41 -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 21946 invoked by uid 89); 30 Dec 2019 00:31:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,FORGED_MUA_MOZILLA,FREEMAIL_FROM,KHOP_HELO_FCRDNS,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.1 spammy=H*r:4.89, Ian, Taylor, lance X-HELO: blaine.gmane.org Received: from 195-159-176-226.customer.powertech.no (HELO blaine.gmane.org) (195.159.176.226) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Dec 2019 00:31:40 +0000 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iliy8-000ulm-7j for gcc@gcc.gnu.org; Mon, 30 Dec 2019 01:31:36 +0100 To: gcc@gcc.gnu.org From: "Julien \"FrnchFrgg\" Rivaud" Subject: Re: Proposal for the transition timetable for the move to GIT Date: Mon, 30 Dec 2019 00:31:00 -0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00531.txt.bz2 Le 29/12/2019 à 18:30, Ian Lance Taylor via gcc a écrit : > On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD > wrote: >> >> 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. > > Out of curiosity, why do you say that merges from trunk to branches > should be rare? It seems to me that any long-lived development branch > will require merges from trunk to the branch. Are you saying that > those kinds of branches are rare? Because in most cases, the development branch should be periodically rebased on top of master, not use a merge from master to the branch. Maybe that's easier to do while developping, but in the end a real rebase should be made (dropping the merge commits), because what you will send to the ML for review should be a logical stream of changes and "update" merge commits are not that. Thankfully, if you have git rerere enabled, most conflict resolutions you did while merging will be reused when rebasing so it should not be too painful. > > In GCC we have historically had a pattern in which people use > long-lived parallel branches that maintain specific patches on top of > GCC trunk. These branches provide a simple way to get a variant of > GCC with specific patches of interest to some people. These branches > too require regular merges from trunk. In that case, sure. But I expect these branches to never be merged in trunk. So the real rule would be « branches that merge from trunk should not be merged into trunk » (rather than « forbid merges into trunk » or even « pretend nobody ever merged anything into trunk, these aren't the droids you are looking for ») > > Ian >