Re: What about allowing multiple hooks?

[Rogan Dawes <lists@dawes.za.net>]

Marc Weber wrote:
> Use case:
> 
> I've been reading parts of the topGit code. And it does make for it to
> add its own checks. However having to change the existing scripts
> insterting a call to the tg hooks isn't the best way.
> Why? one is using #/bin/sh the next is using #/bin/ruby maybe..
> 
> So what about allowing (or even enforcing) ths directory layout?
> 
> .git/hooks/pre-commit/hook1.sh
> .git/hooks/pre-commit/hook2.sh
> .git/hooks/pre-commit/topGitcheck.sh

I second Martin's suggestion, that you implement:

.git/hooks/pre-commit
.git/hooks/pre-commit.d/hook1.sh

where hooks/pre-commit is e.g. a shell script much like the init scripts 
that iterate over the executables in the corresponding .d/ directory, 
and execute them one at a time. Basing your script on initscripts will 
likely save you some time, since they have already considered things 
like script ordering, backups, etc.

I'm also inclined to think that this is likely to be a local 
customisation, because you need to decide what makes sense in your 
context, aborting if a script exits with a non-zero result, or 
continuing to see if the next script manages to exit with a zero result.

e.g. in the pre-commit case, it *probably* makes sense to allow any 
script to abort the commit, but your site-specific requirements might be 
that all hooks must fail to abort the commit.

Regards,

Rogan