> -----Original Message----- > From: git-owner@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx] On > Behalf Of Eugene Sajine > Sent: den 2 juli 2010 21:48 > To: Junio C Hamano > Cc: git@xxxxxxxxxxxxxxx > Subject: Re: global hooks - once again > > On Fri, Jul 2, 2010 at 3:18 PM, Junio C Hamano <gitster@xxxxxxxxx> > wrote: > > Eugene Sajine <euguess@xxxxxxxxx> 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 ��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�