This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Git hooks
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, gcc Mailing List <gcc at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>, Daniel Berlin <dberlin at dberlin dot org>
- Date: Thu, 9 Jan 2020 14:25:59 +0000
- Subject: Re: GCC Git hooks
- Ironport-sdr: bvdObr6OojvVIBurpOTo/de9v/aI4lcOHgDsNjONR2gX3OsVQ6HllbTiah+9G6o8b3Jl5ckpOp VdiiicSZV7qYAlYk0I35I3NXpEWoIIGEJ11+GgDlhu3Nckh7EN08e65UM04ocyc4z9sbb1/vv6 T1ALwzO/cgd70yDcOcyl7xdBEXgOPGQbyxRzGZetMMtf/+IQRYA0tadzeU4IlRfLEdYhjUG71E IAUSIoiINvPOx4/GMS38uOM/xd1BoHpJSaKhTZTixJF9j68NNsoqXSaPR0A1oSAH3ZALgyO67N BNM=
- Ironport-sdr: ifpWj6Eq9oOnYXwbUdq/rf9AMkrUzF2RjGc3ZQ6NO9Za5NhivN+upygCiKHHTM2PJbjBQk0J/j MUn5dzs/r4UnKgAoiP/+jJYh2K3L4rFou2SFeVvC/7X60XwObLjatoCaskK3dKfhSXluzle0KO XKoH+e6ZTMcCF0lbIbX0vu/eRfHoAouvOwTsw36ZzArh2fWLDxe7SFw0ZCXTMYvflpivtvn3D+ LV6MB2Jt89R91OK0mTQou/m0E6h9+hhayY7Yl79COx8ktqAGCkWbNQVmxMcsE4HT21KtEbG1xI RSY=
- References: <CADzB+2mqKfG2iEfHZXsv5qJ_U8NQ-cGTgvGRgPWi-5mj3Hot_A@mail.gmail.com> <20190916150650.GB4945@adacore.com>
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/<vendor>/{heads,tags} and
refs/users/<user>/{heads,tags} scheme described at
<https://gcc.gnu.org/ml/gcc/2019-11/msg00249.html>, 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.
* 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.
--
Joseph S. Myers
joseph@codesourcery.com