Re: [PATCH v2 0/7] Multiple hook support

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 14, 2019, 00:51 UTC
Message-ID: <20190514004920.GB136746@google.com>
In-Reply-To: <20190514002332.121089-1-sandals@crustytoothpaste.net>

Hi,

brian m. carlson wrote:

Show 7 quoted lines

> 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
> user.

Can we discuss this some more? What would it take to make it likely to be useful in your view?

Show 5 quoted lines

> 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.

Thanks, Jonathan