TO-DO list of niceties for the future of Git::Hooks.

The following list is in approximately my order of implementation intention. Any comments or other suggestion are welcome at gnustavo AT

Simplify plugin/hook integration

Currently, if a plugin may be hooked to more than one hook, one must configure all the integrations by hand. For instance, the CheckJira plugin can be hooked to the update, the pre-receive, and the commit-msg hooks, and the user has to know which hooks must be enabled. It would be easier if the plugins could hook themselves to all hooks directly. In this way, for instance, instead of configuring CheckJira specifically for one of those hooks with one of the following configurations:

    git config --add githooks.commig-msg  CheckJira
    git config --add githooks.pre-receive CheckJira
    git config --add githooks.update      CheckJira

One would simply do this:

    git config --add githooks.plugin CheckJira

CheckJira would automatically be enabled for all plugins, which would not even make it less efficient, because normally only one of those hooks would be invoked in a single operation. (The commit-msg plugin would be invoked in a commit and the other two in a push. But, on the server the user would probably link either the pre-receive or the update hook to the generic script, so that only one of them would be effectively invoked during the operation.)

Implement the Git::Hooks::SafeRewrite plugin

Implement a plugin to check the safety of rewrites, by detecting when we're amending or rebasing commits that have already been pushed. Here are some discussion about this:

The rebase check could be performed in a pre-rebase hook. But there is no way to check for an amended commit before it's done. One idea would be to record the HEAD's parents in a file during a pre-commit hook and produce an alert during a post-commit hook if the HEAD's parents are the same. In this case, the alert should provide the command that should be performed to revert the amend.

Find a substitute for App::gh::Git

The Git::More module currently inherits from App::gh::Git, augmenting its functionality with some methods useful for hooks and caching information to speed up things. The App::gh::Git has some problems, though, which led me to want to substitute another Git wrapper for it as a base for Git::More. Two of the finest candidates on CPAN are Git::Wrapper and Git::Repository.

Support the WIN32 Platform

Currently we abort the build on Makefile.PL.

Implement the Scott Chacon example hooks


In CheckAcls implement DENY for ACL operations

Along the lines of NFSv4 ACLs ( I'm thinking about prefixing the what component with a '!'.

Implement equivalents for the SVN::Hooks plugins

In Currently we're missing DenyFilenames and UpdateConfFile. Actually, I'm thinking that UpdateConfFile is too much specific. Perhaps something along the lines of this post-update hook would be more interesting:

Let the user control which config files to read

Let the user tell which configuration files Git::Hooks should consider. Currently it considers the three default ones (system, global, and local), without knowing which one sets what. Perhaps we could have a new option githooks.extra_config that could be set with an array of filenames to invoke git config --file with in succession. This option, if set in the default configuration files, could tell Git::Hooks to grok an extra set of configuration from specific files.

In CheckLog allow for stop words

CheckLog.spelling should have a way to register stop words. I'd have to ask for a change in Text::SpellChecker.

The Gerrit default commit-msg implements some checks that could be used here. Some other things to check:

Require Signed-off-by lines (
Duplicate Signed-off-by lines (

Implement the Git::Hooks::CheckFile plugin

Implement a hook to make it easy to perform some checks on added/modified files. For instance, Perl files should be syntax checked. This could be configured somewhat like this:

    CheckFile.rule "\.p[lm]$ perl -c"

The first 'word' in the value would be a regexp used to match the files we're interested in. All that follows would be a command to which the filename would be passed.

This would allow for all kinds of checks specific for some kinds of files. Some interesting ideas here: