* global hooks - once again @ 2010-07-02 16:23 Eugene Sajine 2010-07-02 18:03 ` Jonathan Nieder 2010-07-02 19:18 ` Junio C Hamano 0 siblings, 2 replies; 14+ messages in thread From: Eugene Sajine @ 2010-07-02 16:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-02 16:23 global hooks - once again Eugene Sajine @ 2010-07-02 18:03 ` Jonathan Nieder 2010-07-02 19:30 ` Eugene Sajine 2010-07-02 19:18 ` Junio C Hamano 1 sibling, 1 reply; 14+ messages in thread From: Jonathan Nieder @ 2010-07-02 18:03 UTC (permalink / raw) To: Eugene Sajine; +Cc: git 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-02 18:03 ` Jonathan Nieder @ 2010-07-02 19:30 ` Eugene Sajine 0 siblings, 0 replies; 14+ messages in thread From: Eugene Sajine @ 2010-07-02 19:30 UTC (permalink / raw) To: Jonathan Nieder; +Cc: git 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-02 16:23 global hooks - once again Eugene Sajine 2010-07-02 18:03 ` Jonathan Nieder @ 2010-07-02 19:18 ` Junio C Hamano 2010-07-02 19:47 ` Eugene Sajine 2010-07-02 20:53 ` Jonathan Nieder 1 sibling, 2 replies; 14+ messages in thread From: Junio C Hamano @ 2010-07-02 19:18 UTC (permalink / raw) To: Eugene Sajine; +Cc: git 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-02 19:18 ` Junio C Hamano @ 2010-07-02 19:47 ` Eugene Sajine 2010-07-05 10:03 ` Peter Kjellerstedt 2010-07-06 14:34 ` demerphq 2010-07-02 20:53 ` Jonathan Nieder 1 sibling, 2 replies; 14+ messages in thread From: Eugene Sajine @ 2010-07-02 19:47 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: global hooks - once again 2010-07-02 19:47 ` Eugene Sajine @ 2010-07-05 10:03 ` Peter Kjellerstedt 2010-07-06 12:14 ` Alex Riesen 2010-07-06 12:20 ` Eugene Sajine 2010-07-06 14:34 ` demerphq 1 sibling, 2 replies; 14+ messages in thread From: Peter Kjellerstedt @ 2010-07-05 10:03 UTC (permalink / raw) To: Eugene Sajine, Junio C Hamano; +Cc: git > -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-05 10:03 ` Peter Kjellerstedt @ 2010-07-06 12:14 ` Alex Riesen 2010-07-06 12:23 ` Eugene Sajine 2010-07-06 12:20 ` Eugene Sajine 1 sibling, 1 reply; 14+ messages in thread From: Alex Riesen @ 2010-07-06 12:14 UTC (permalink / raw) To: Peter Kjellerstedt; +Cc: Eugene Sajine, Junio C Hamano, git 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-06 12:14 ` Alex Riesen @ 2010-07-06 12:23 ` Eugene Sajine 2010-07-06 14:55 ` Peter Kjellerstedt 0 siblings, 1 reply; 14+ messages in thread From: Eugene Sajine @ 2010-07-06 12:23 UTC (permalink / raw) To: Alex Riesen; +Cc: git > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: global hooks - once again 2010-07-06 12:23 ` Eugene Sajine @ 2010-07-06 14:55 ` Peter Kjellerstedt 2010-07-06 15:00 ` demerphq 0 siblings, 1 reply; 14+ messages in thread From: Peter Kjellerstedt @ 2010-07-06 14:55 UTC (permalink / raw) To: Eugene Sajine, Alex Riesen; +Cc: git > -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-06 14:55 ` Peter Kjellerstedt @ 2010-07-06 15:00 ` demerphq 2010-07-06 15:32 ` Eugene Sajine 0 siblings, 1 reply; 14+ messages in thread From: demerphq @ 2010-07-06 15:00 UTC (permalink / raw) To: Peter Kjellerstedt; +Cc: Eugene Sajine, Alex Riesen, git 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/" ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-06 15:00 ` demerphq @ 2010-07-06 15:32 ` Eugene Sajine 0 siblings, 0 replies; 14+ messages in thread From: Eugene Sajine @ 2010-07-06 15:32 UTC (permalink / raw) To: demerphq; +Cc: Peter Kjellerstedt, Alex Riesen, git > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-05 10:03 ` Peter Kjellerstedt 2010-07-06 12:14 ` Alex Riesen @ 2010-07-06 12:20 ` Eugene Sajine 1 sibling, 0 replies; 14+ messages in thread From: Eugene Sajine @ 2010-07-06 12:20 UTC (permalink / raw) To: Peter Kjellerstedt; +Cc: Junio C Hamano, git > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-02 19:47 ` Eugene Sajine 2010-07-05 10:03 ` Peter Kjellerstedt @ 2010-07-06 14:34 ` demerphq 1 sibling, 0 replies; 14+ messages in thread From: demerphq @ 2010-07-06 14:34 UTC (permalink / raw) To: Eugene Sajine; +Cc: Junio C Hamano, git 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/" ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: global hooks - once again 2010-07-02 19:18 ` Junio C Hamano 2010-07-02 19:47 ` Eugene Sajine @ 2010-07-02 20:53 ` Jonathan Nieder 1 sibling, 0 replies; 14+ messages in thread From: Jonathan Nieder @ 2010-07-02 20:53 UTC (permalink / raw) To: Junio C Hamano; +Cc: Eugene Sajine, git 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-07-06 15:32 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-07-02 16:23 global hooks - once again Eugene Sajine 2010-07-02 18:03 ` Jonathan Nieder 2010-07-02 19:30 ` Eugene Sajine 2010-07-02 19:18 ` Junio C Hamano 2010-07-02 19:47 ` Eugene Sajine 2010-07-05 10:03 ` Peter Kjellerstedt 2010-07-06 12:14 ` Alex Riesen 2010-07-06 12:23 ` Eugene Sajine 2010-07-06 14:55 ` Peter Kjellerstedt 2010-07-06 15:00 ` demerphq 2010-07-06 15:32 ` Eugene Sajine 2010-07-06 12:20 ` Eugene Sajine 2010-07-06 14:34 ` demerphq 2010-07-02 20:53 ` Jonathan Nieder
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.