From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103698 invoked by alias); 10 Jan 2020 18:15: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 103527 invoked by uid 89); 10 Jan 2020 18:15:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=our X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2020 18:15:39 +0000 IronPort-SDR: 9fPV88RP1CCND7V18M4YQIKyLp+P6qTr3tirjJKCAi+bJWDt3baIrt4+1KQUEH3ezDQW4y9QlL TLjtxICvTp2SqAeQPgtqW+zd7fUU4so2IlGVSX77LGRlQxFuwcgRn1Xm5BzyR1t6rTCTiYBKtW 2MB/yuumkPGYREvcxfgaIjmSmStlBPJwLEv+IGfMVxXemqWWefM2NHKDFkGsDiaaDtJJhYmc6m NQbW99TwP3rUlPy6NoaszANFq8oV4Cu6om15FQqrK1lHCmhOygx4lVDiNlkIckb0KasKp7aYCb A7o= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 10 Jan 2020 10:15:36 -0800 IronPort-SDR: 2508CgCC2PXM7+YqsfvR0BFDMy3EUZ8dIJwUrT3N6rWitXkCb5mOTPDkMhCmISHQf7g+Z33NS/ FOQxM+uxrAcx0fSAXLhLy92Q+VyTst899t+8E3IIa9fm7ruk/DzhGcb9xE4A+cut93EG7sHVIR WsYDTnPBj7gxnLP0KrqijDxzBGSHm8fcwWKwt5punSVpwKu9xWAMu8twxGE/CSl8CaqKfViwSs DDCHAvZOcGMDFoKv+iYntJT+QFDJyirFRyWamXFRdZuIBkRnMmwnvwBYIJZCVRgHTYiamJc6Kn s+I= Date: Fri, 10 Jan 2020 18:15:00 -0000 From: Joseph Myers To: Joel Brobecker CC: Jason Merrill , Maxim Kuvyrkov , gcc Mailing List , Gerald Pfeifer , Daniel Berlin Subject: Re: GCC Git hooks In-Reply-To: <20200110180049.GH3313@adacore.com> Message-ID: References: <20190916150650.GB4945@adacore.com> <20200110180049.GH3313@adacore.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2020-01/txt/msg00140.txt.bz2 On Fri, 10 Jan 2020, Joel Brobecker wrote: > > Plus one further change now: if a newly created branch is in refs/heads/, > > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e. > > enforce a particular branch naming convention, in particular to prevent > > mistakes where people accidentally push a branch into refs/heads/ because > > their push configuration for user or vendor branches was wrong). > > I'm having a hard time understanding this requirement. > > You want to say that, before branch "" gets created, you want > to verify that a branch named either "devel/" or "releases/" > does exist? No. What we want to ensure is that people don't accidentally create a branch called refs/heads/foo when they should (by our naming conventions) have created one called refs/heads/devel/foo or refs/users/someone/heads/foo. Our naming conventions mean that all branches in refs/heads/ should be called master, devel/something or releases/something. But it's easy for someone to get a "git push" command wrong so that it would create a badly named branch. -- Joseph S. Myers joseph@codesourcery.com