global hooks - once again

global hooks - once again

[Eugene Sajine]

I have found a thread dated March 2008 about the subject, but there
was no acceptable solution provided.
Template directory doesn't seem to be interesting.

Is there a better way now?

If there is no better way now Is it possible to create a git config
property specifying where the global hooks folder is and then look for
hooks there first and then in the repo or vice versa?

For example, so i could say
$ git config --global hooks.dir ~/git/hooks

It could even attempt to create the specified folder and create
necessary structure in it like below if necesary
/pre-commit
/post-commit
/pre-rebase
/post-rebase

etc...

Thanks,
Eugene

Re: global hooks - once again

[Jonathan Nieder]

Eugene Sajine wrote:

> I have found a thread dated March 2008 about the subject, but there
> was no acceptable solution provided.

Link?

> If there is no better way now Is it possible to create a git config
> property specifying where the global hooks folder is and then look for
> hooks there first and then in the repo or vice versa?

Well, I like the idea[1].  The design issues are not very complicated;
the main thing is to implement it.

 $ git grep -l -F -e 'hooks/' -- \*.c \*.sh \*.perl | egrep -v '^(contrib/(examples|hooks))|t/'
 builtin/commit.c
 builtin/init-db.c
 builtin/receive-pack.c
 git-am.sh
 git-cvsserver.perl
 git-rebase--interactive.sh
 git-rebase.sh
 run-command.c

Hope that helps,
Jonathan

[1] e.g., for http://bugs.debian.org/514651

Re: global hooks - once again

[Junio C Hamano]

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.

But it is understandable for one to use more than one repository for the
same project and use them in the same way; in such a case, I agree that a
way to ensure that these repositories use the same set of hooks (and
non-hooks, e.g. commit templates, local ignore pattern files, etc.) is
desirable.

So I would imagine that your example without "--global" would be a
reasonable thing to do once per repository.

Now, as long as the "do once per repository" action that you need to do is
simple enough, it doesn't necessarily have to be "git config".  Perhaps

    [alias]
    set-hooks = !"sh -c 'rm -fr .git/hooks && ln -s $1 .git/hooks' -"

could also be a simple single-command solution that is "do once per
repository".

Can't we do better and make this "do nunce per repository" instead?

You first have to think how you are creating these more-than-one
repositories you would want to make sure they use the same hooks.  For
example, do you have a single "upstream" repository and everything is a
clone of it?  If so, perhaps a way to tell "clone" via $HOME/.gitconfig
that when cloning from a particular URL you would want to run a particular
post-clone script might be a better way.

Re: global hooks - once again

[Eugene Sajine]

On Fri, Jul 2, 2010 at 2:03 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Eugene Sajine wrote:
>
>> I have found a thread dated March 2008 about the subject, but there
>> was no acceptable solution provided.
>
> Link?

http://search.gmane.org/?query=global+hooks&group=gmane.comp.version-control.git

Thanks,
Eugene

Re: global hooks - once again

[Eugene Sajine]

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.
In addition, i don't think there is a downside in this particular
example as it is not a mandatory property that I propose. If you need
a global hook there should be an easy way to work with it. If you
don't need it - just don't touch anything and work on per repo basis.

>
> But it is understandable for one to use more than one repository for the
> same project and use them in the same way; in such a case, I agree that a
> way to ensure that these repositories use the same set of hooks (and
> non-hooks, e.g. commit templates, local ignore pattern files, etc.) is
> desirable.
>
> So I would imagine that your example without "--global" would be a
> reasonable thing to do once per repository.

once again it is only a part of use cases. there might be several
repos/projects for one user. --global is necessary option
I'm talking about user level hooks. He has no admin access to
/usr/local/ and too many repos to deal with each one of them and set
up hooks per repo.


>   [alias]
>   set-hooks = !"sh -c 'rm -fr .git/hooks && ln -s $1 .git/hooks' -"

This is good one, but not enough. Not that it is too difficult to
execute it 40 times, but just the fact that in order to understand how
to do that i had to write to git list;) Having it in git config makes
it straight forward for end user and much user "friendlier"

Thanks,
Eugene

Re: global hooks - once again

[Jonathan Nieder]

Junio C Hamano wrote:

> Now, as long as the "do once per repository" action that you need to do is
> simple enough, it doesn't necessarily have to be "git config".  Perhaps
> 
>     [alias]
>     set-hooks = !"sh -c 'rm -fr .git/hooks && ln -s $1 .git/hooks' -"

It is not difficult to set up hook scripts when initializing a
repository.  In fact git clone --template= and the “[init]
templatedir” configuration work pretty well.  What is more difficult
is to change the list of hook scripts later.

If I symlink the entire hooks dir like you describe, I cannot override
a couple of hooks per-repository without teaching the hook scripts to
handle that themselves.  (something like:

	hook=$(basename "$0")
	! test -e "$GIT_DIR/local-hooks/$hook.disable" || exit 0
	! test -e "$GIT_DIR/local-hooks/$hook" ||
		exec "$GIT_DIR/local-hooks/$hook"

)  Maybe that is the simplest solution.

RE: global hooks - once again

[Peter Kjellerstedt]

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

Re: global hooks - once again

[Alex Riesen]

On Mon, Jul 5, 2010 at 12:03, Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
> 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.

How do your users disable execution of global hooks in this scheme?
(to protect themselves from an evil system administrator)

Re: global hooks - once again

[Eugene Sajine]

> 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

Re: global hooks - once again

[Eugene Sajine]

>
> How do your users disable execution of global hooks in this scheme?
> (to protect themselves from an evil system administrator)
>
In a corporate environment it is not the case, i believe. If sysadmin
made a mistake a with hooks, he will have to fix it, but there is no
point in overriding on user level as hooks in this case will be
something about company policy, aren't they?

Thanks,
Eugene

Re: global hooks - once again

[demerphq]

On 2 July 2010 21:47, Eugene Sajine <euguess@gmail.com> wrote:
> 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,

$work is like this. Any repo on our version control host will share a
common set of hooks.

yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

RE: global hooks - once again

[Peter Kjellerstedt]

> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Eugene Sajine
> Sent: den 6 juli 2010 14:23
> To: Alex Riesen
> Cc: git@vger.kernel.org
> Subject: Re: global hooks - once again
> 
> > How do your users disable execution of global hooks in this scheme?
> > (to protect themselves from an evil system administrator)

Yeah, I missed that case. What I have is another configuration 
variable (e.g., core.hooksActiveLevels) which is set to a string of 
different configuration levels (defaulting to 'system global local').
Only the hook directories specified on an active level are
scanned for hooks. So by setting it to just 'local' any system
and global hook directories are ignored.

This is not optimal, but was the best I could come up with.
I really do not want to force the users to explicitly specify
the hook directories for each repository, but rather be able 
to set it on a global level, and then use exceptions for the 
few cases where the global hooks should not be active.

> In a corporate environment it is not the case, i believe. If sysadmin
> made a mistake a with hooks, he will have to fix it, but there is no
> point in overriding on user level as hooks in this case will be
> something about company policy, aren't they?

Well, actually it is needed there too. Even though the vast 
majority of repositories the user clones are company repositories
that should use the company's rules, he may clone some occasional
repositories from the outside (e.g., Linux or git) in which case
he probably wants to disable the global company hooks.

> Thanks,
> Eugene

//Peter

Re: global hooks - once again

[demerphq]

On 6 July 2010 16:55, Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote:
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
>> Behalf Of Eugene Sajine
>> Sent: den 6 juli 2010 14:23
>> To: Alex Riesen
>> Cc: git@vger.kernel.org
>> Subject: Re: global hooks - once again
>>
>> > How do your users disable execution of global hooks in this scheme?
>> > (to protect themselves from an evil system administrator)
>
> Yeah, I missed that case. What I have is another configuration
> variable (e.g., core.hooksActiveLevels) which is set to a string of
> different configuration levels (defaulting to 'system global local').
> Only the hook directories specified on an active level are
> scanned for hooks. So by setting it to just 'local' any system
> and global hook directories are ignored.
>
> This is not optimal, but was the best I could come up with.
> I really do not want to force the users to explicitly specify
> the hook directories for each repository, but rather be able
> to set it on a global level, and then use exceptions for the
> few cases where the global hooks should not be active.
>
>> In a corporate environment it is not the case, i believe. If sysadmin
>> made a mistake a with hooks, he will have to fix it, but there is no
>> point in overriding on user level as hooks in this case will be
>> something about company policy, aren't they?
>
> Well, actually it is needed there too. Even though the vast
> majority of repositories the user clones are company repositories
> that should use the company's rules, he may clone some occasional
> repositories from the outside (e.g., Linux or git) in which case
> he probably wants to disable the global company hooks.

Id have guessed that users would be discouraged from having their own
repositories on a central version control server in most larger
environments.

For instance i can imagine that boxes that devs actively work on would
have no global setting, and central version control boxes would have
it.

cheers,
Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: global hooks - once again

[Eugene Sajine]

> For instance i can imagine that boxes that devs actively work on would
> have no global setting, and central version control boxes would have
> it.
>
> cheers,
> Yves
>

I suppose the default configuration is not suggesting any system or
global level hooks folders defined in proposed solution. If some admin
or SCM makes a decision about system level hooks - he has to know what
he's doing - that's is pretty much it. But it might be very
comfortable way to set up some rules or enforce policies.
OTOH user level (--global) hooks are going to be responsible for what
user does all the time and wants to automate.


Thanks,
Eugene