Re: What about allowing multiple hooks?

From: Rogan Dawes <lists@dawes.za.net>
Date: Nov 21, 2008, 14:56 UTC
Message-ID: <4926CC03.4000009@dawes.za.net>
In-Reply-To: <20081121133828.GB5912@gmx.de>

Marc Weber wrote:

Show 12 quoted lines

> 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