Hi, 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 > user. 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. Thanks, Jonathan
