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