RE: global hooks - once again

[Peter Kjellerstedt <peter.kjellerstedt@axis.com>]

> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Eugene Sajine
> Sent: den 2 juli 2010 21:48
> To: Junio C Hamano
> Cc: git@vger.kernel.org
> Subject: Re: global hooks - once again
> 
> On Fri, Jul 2, 2010 at 3:18 PM, Junio C Hamano <gitster@pobox.com>
> wrote:
> > Eugene Sajine <euguess@gmail.com> writes:
> >
> >> For example, so i could say
> >> $ git config --global hooks.dir ~/git/hooks
> >
> > I don't think "global" hooks are useful for people who work on 
> > more than one project, or people who interact in more than one 
> > ways to projects.
> > Different projects typically have different needs out of the hooks
> > (e.g. pre-commit policy), and different workflows typically call 
> > for different needs out of the hooks (e.g. I would want to be able 
> > to rebase in my private working repository but not in the repository 
> > I use for integration of other people's branches).
> >
> > So I am fairly negative on your particular example above.
> 
> Well, you forgot about another half of users that are working with
> many projects but using one policy for example in one company, or if
> the guy works with several projects, but wants some of his custom
> hooks to be applied for all his repos/projects, for example if he want
> some general actions to be executed before commit, like spell check of
> the commit message. If I have 40 repos --global approach is the way to
> go.

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