From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39401 invoked by alias); 10 Jan 2020 17:38:55 -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 39390 invoked by uid 89); 10 Jan 2020 17:38:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=exceed, clever, convince 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:38:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3027856002; Fri, 10 Jan 2020 12:38:52 -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 jNqXgKxSoYwg; Fri, 10 Jan 2020 12:38:52 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9DF2B56001; Fri, 10 Jan 2020 12:38:51 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4821382B7F; Fri, 10 Jan 2020 21:38:47 +0400 (+04) Date: Fri, 10 Jan 2020 17:38: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: <20200110173847.GF3313@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/msg00133.txt.bz2 Hi Joseph, Apologies for the slow replies. The end of this week has been pretty packed, and next week will be as well. But I will make sure we answer every questions and suggestions you have! On Thu, Jan 09, 2020 at 02:25:59PM +0000, Joseph Myers wrote: > On Mon, 16 Sep 2019, Joel Brobecker wrote: > > > Looking at the configuration file, I believe the git-hooks > > should have most, if not all, of the features that would be needed for > > the GCC repository. In particular, there is already a way to relay > > commits to third-party tools via calling of a script; GDB uses that > > to interface with their Bugzilla database. > > I am now looking at the hook setup for GCC. As far as I can see, I'll > initially need a GCC-specific fork of the hooks for two reasons: > > * Custom ref naming. The refs/vendors//{heads,tags} and > refs/users//{heads,tags} scheme described at > , to avoid such branches > being fetched by default, will need the hooks to know that such ref names > are to be treated as branches / tags, and to allow non-fast-forward pushes > to them. That's actually a neat way of dealing with vendor branches. I have always felt it was suboptimal that everyone had to fetch updates in vendor branches in the GDB repositories. I don't know if I could convince the GDB community to use this scheme, but I think it's pretty clever. I'll make sure there is a way to handle that without needing to create your own version of the git-hooks. > * I don't see a configuration option to add custom checks before accepting > a ref update. I think we want a custom check that prevents people for > accidentally pushing merges between the old and new versions of the GCC > history. It's easy to write something called from a pre-receive / update > hook that uses git rev-list to identify problem pushes, but doing that > without a fork of the hooks would require a suitable configuration option > to call out to such a custom script. I think an update-hook setting allowing repositories to have a script called to perform additional ad hoc verifications sounds like it could be generally useful. For the specific issue that you are trying to protect against, that's unlikely to happen, IMO. When someone pushes a commit, what the hooks do is look at the list of commits which are being added to that branch. If the number of such commits exceed a limit (100 by default), it rejects that push. I think a user trying to push a merge that points to the old history will hit that rejection. I will add both of these features to my TODO list. -- Joel