On Tue, Apr 23, 2019 at 07:34:38PM -0700, Jonathan Nieder wrote:
> 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.

> 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