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@xxxxxxxxxxxxxxxxxxxxxxxxx/ > 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
Attachment:
signature.asc
Description: PGP signature
