> Well, I belong to this secondary category, working for a company > which is about to switch to git. Once the transition is completed, > we will have more than 800 git repositories, and they should all > have a basic set of hooks (e.g., commit message validation, > permissions checking, mail sending). Making our 100+ developers > manually set up the hooks for each repository they clone is not an > option. > > So what I have done is setup a template directory with hooks being > a link to a pre-installed directory, where each hook is linked to a > single script. This script then reads from a directory called > hooks.d which is a drop directory for hooks. Each hook then has the > format '<hook>.<order>.<name>' (e.g., 'post-receive.10.send_mail'), > somewhat similar to /etc/rcX.d. It will also look in a .githooks.d > directory in the working directory (this can be disabled with a > config option). This is used by repository owners who want to add > extra hooks for their repositories, e.g., to add automatic code > indentation before commit, or unit testing. It is also possible > to specify more hook directories with a multi-value config option, > which the user can use if he/she likes to add some personal hooks. > All hooks found in all drop directories are sorted by order before > being executed so that it is possible to add local hooks before or > after the global ones. > > This way it is possible to have system level hooks, repository > specific hooks and user specific hooks all work together. And even > though I now have a system which works for us, having something like > this in the git core would be more efficient, and benefit more users. > > Here is what my solution explained above would look like if it was > added to the git core. > > * The .git/hooks directory is replaced by .git/hooks.d (any hooks > found in .git/hooks could be assumed to have an order of 50 for > backwards compatibility). > * If core.repositoryHooks (better name?) is true (default to false) > then .githooks.d in the working directory is searched for hooks. > * It is possible to specify more hook directories using the > multi-value core.hookDirectory option (directories are relative to > the .git directory; absolute directories are of course also allowed). > > //Peter > > To me this is another confirmation that not only --global but also --system level config variable specifying hooks folder is necessary. I mean company wide hooks (system) are combined with users global and repo specific ones. Seems to be obvious. Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html