Re: [PATCH v2 0/7] Multiple hook support
- Date: Mon, 13 May 2019 17:51:01 -0700
- From: Jonathan Nieder <jrnieder@xxxxxxxxx>
- Subject: Re: [PATCH v2 0/7] Multiple hook support
brian m. carlson wrote:
> I've thought a lot about the discussion over whether this series should
> use the configuration as the source for multiple hooks. Ultimately, I've
> come to the decision that it's not a good idea. Even adopting the empty
> entry as a reset marker, the fact that inheritance in the configuration
> is in-order and can't be easily modified means that it's not likely to
> be very useful, but it is likely to be quite surprising for the average
Can we discuss this some more? What would it take to make it likely
to be useful in your view?
> I think a solution that sticks with the existing model and builds
> off a design used by other systems people are familiar with, like cron
> and run-parts, is going to be a better choice. Moreover, this is the
> design that people have already built with outside tooling, which is a
> further argument in favor of it.
To be clear, the main advantage I see for config versus the .git/hooks
model is that with the config model, a user doesn't have to search
throughout the filesystem for .git/hooks directories to update when a
hook is broken.
There are other models that similarly fix that --- e.g. putting hooks
in /etc. But as long as they're in .git/hooks, I think we're digging
ourselves deeper into the same hole.