Re: [PATCH 0/5] Multiple hook support

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 24, 2019, 23:07 UTC
Message-ID: <20190424230744.GL6316@genre.crustytoothpaste.net>
In-Reply-To: <20190424023438.GE98980@google.com>

On Tue, Apr 23, 2019 at 07:34:38PM -0700, Jonathan Nieder wrote:

Show 11 quoted lines

> Hi,
> 
> brian m. carlson wrote:
> 
> > I've talked with some people about this approach, and they've indicated
> > they would prefer a configuration-based approach.
> 
> I would, too, mostly because that reduces the problem of securing
> hooks to securing configuration.  See
> https://public-inbox.org/git/20171002234517.GV19555@aiede.mtv.corp.google.com/
> for more on this subject.

I know this is a common issue, but fixing it is a non-goal for this series. Anything we do here is going to have to be backwards compatible, so we can't make any changes to the security model.

Show 9 quoted lines

> Solving (1) without (2) feels like a bit of a missed opportunity to
> me.  Ideally, what I would like is
> 
>    i. A central registry of trustworthy Git hooks that can be upgraded
>       using the system package manager to address (2).  Perhaps just
>       git-hook-* commands on the $PATH.
> 
>   ii. Instead of putting hooks in .git/hooks, put a list of hooks to
>       run for each event in .git/config.

The problem I had with this when discussing it was that our configuration system lacks a good way to control inheritance from outer files. I recently was working with a system-wide gitconfig file that referred to files I didn't have, and my Git installation was subtly broken in a variety of ways.

If I have a system-wide hook to run for company code, but I have a checkout for my personal dotfiles on my machine where I don't want to run that hook, our configuration lacks a way for me to disable that system-wide configuration. However, using our current system, I can override core.hooksPath in this case and everything works fine.

I mentioned this for completeness, and because I hope that some of those people will get some time to chime in here, but I think without that feature, we end up with a worse experience than we have now.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204