From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91283 invoked by alias); 10 Jan 2020 17:57:03 -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 91272 invoked by uid 89); 10 Jan 2020 17:57:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1308, interest X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2020 17:57:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1E2991172E3; Fri, 10 Jan 2020 12:57:01 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qRUK0-X3AUMr; Fri, 10 Jan 2020 12:57:01 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AF2AF1172DF; Fri, 10 Jan 2020 12:57:00 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 5B18F82B7F; Fri, 10 Jan 2020 21:56:56 +0400 (+04) Date: Fri, 10 Jan 2020 17:57:00 -0000 From: Joel Brobecker To: Joseph Myers Cc: Jason Merrill , Maxim Kuvyrkov , gcc Mailing List , Gerald Pfeifer , Daniel Berlin Subject: Re: GCC Git hooks Message-ID: <20200110175656.GG3313@adacore.com> References: <20190916150650.GB4945@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2020-01/txt/msg00135.txt.bz2 > * Additional branch namespaces refs/users//heads and > refs/vendors//heads, and similar tag namespaces > refs/users//tags and refs/vendors//tags. Hmmm. Note to self: I missed the fact that this namespace was also used for tags. > * Only allowing branch deletion for certain ref patterns (refs/users and > refs/vendors in this case). Once we add support for the update-hook, I think you'll be able to implement that feature there. This might be of general interest however, so I'll think about something. Up until now, the configuration options taking patterns have always taken pattern that activate the option of they match. Here, we want "turn this option on, except in those cases". Maybe the way to go is to have two options, both related: - allow-branch-deletion (default: True) - branch-deletion-exception (default: empty list) The second option is ignored if allow-branch-deletion is True. Project that want to reject them all, just sets the option to False. Projects like GCC then use both: allow-branch-deletion: True branch-deletion-exception = branch-deletion-exception = > * Controlling when non-fast-forward pushes are allowed for ref patterns > outside refs/heads. OK. -- Joel