Brian Collins [off-list ref] writes:
Run global hooks in the directory specified by the config variable
hooks.dir before every attempt at running a local hook. If the
global hook fails, the local hook will not run. If the global hook is
absent, the local hook runs normally.
It is left unspecified what happens when the global hook exists and it
succeeds. Watch out for hooks that read from their standard input.
In any case, the above is totally backwards from the usual practice and
expectation of local things overriding the global default. If you want a
site-wide policy suggestion, default templates would be a more acceptable
way (and the implementation of hooks you install to developer repositories
can choose to look at $GIT_DIR/hooks/local-foo-hook).
By the way, with a distributed scm, anything-wide policy enforcement at
the level of developer's individual working repositories is a lost cause.
You are giving freedom to do anything on their own copy of the history to
the developers; the project-wide policy is to be enforced at the perimeter
of your authoritative repository of the project.
It is left unspecified what happens when the global hook exists and it
succeeds. Watch out for hooks that read from their standard input.
The local hook will execute. They are chained.
In any case, the above is totally backwards from the usual practice and
expectation of local things overriding the global default. If you want a
site-wide policy suggestion, default templates would be a more acceptable
way (and the implementation of hooks you install to developer repositories
can choose to look at $GIT_DIR/hooks/local-foo-hook).
The global hook doesn't override the local hook, it supplements it. In any
case, a developer can set hooks.dir to be something else in a specific
repository, and it will override the global default.
By the way, with a distributed scm, anything-wide policy enforcement at
the level of developer's individual working repositories is a lost cause.
You are giving freedom to do anything on their own copy of the history to
the developers; the project-wide policy is to be enforced at the perimeter
of your authoritative repository of the project.
The developer is in total control, it is a user configuration option.
It is the same
as setting colours for diffs. Just a preference that makes the developer's life
easier by adding some way of automating certain tasks. Say you want to
post to IRC every time you commit, this could do that. Or if you want to set up
a shell script to jump to your most recently used repository. There are lots of
possible applications. I admit "site-wide coding style enforcement" was a bad
example, and I certainly don't plan to use it for that.