The following list is in approximately my order of implementation intention. Any comments or other suggestion are welcome at gnustavo AT cpan.org.
Currently we abort the build on
Currently, when a plugin detects a problem it calls die and the hook is aborted immediately. It would be better if the plugins could register the errors they detect along the way so that Git::Hooks could show the user the complete list of problems.
A specific problem that would be solved would be this. Currently, when a commit is rejected due to a failed check in a plugin, the user gets an error message. If it is an inconsequential problem the user might decide to bypass the commit checks by passing the -n option to disable the hooks altogether. Or he may disable the specific plugin by defining an environment variable. Either way, the commit might have other problems that got undetected simply because the hook aborted after detecting the first one. When the user disables all or some checks he may well be letting pass other errors.
Yet another argument for this new mechanism is that it is necessary if we want to implement Gerrit's asynchronous hooks.
Gerrit is a "web based code review and project management tool for Git based projects" (https://code.google.com/p/gerrit/). It's based on JGit (http://eclipse.org/jgit/) which, as of 2012-01-14, still doesn't support git's standard hooks.
But Gerrit has its own hook infrastructure and we should support it (http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.1/config-hooks.html).
The two hooks that seem to be relevant to Git::Hooks's plugins are patchset-created and ref-updated.
Use Locale::TextDomain to internationalize it.
As a first job after i18n I intend to nationalize it to Brazilian Portuguese.
Let the user tell which configuration files Git::Hooks should consider.
Currently it considers the three default ones (system,
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.
if set in the default configuration files,
could tell Git::Hooks to grok an extra set of configuration from specific files.
Along the lines of NFSv4 ACLs (http://tools.ietf.org/html/rfc5661#section-6). I'm thinking about prefixing the what component with a '!'.
In http://search.cpan.org/dist/SVN-Hooks/. 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: http://stackoverflow.com/questions/279169/deploy-a-project-using-git-push.
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:
Some people (e.g. Linus Torvalds) prefer spaces, others prefer tabs.
Some people prefer tab size at 8 characters, others prefer at 4.
This plugin should be able to check these preferences for selected types of files. Some configuration would be like this:
By default any kind of white-space should be allowed. But one could specify tab for tabs only or space for space only.
Note that this checks only the indentation space in each line.
This multi-valued option defines the files that should be checked. By default, no file is checked.
By default trailing white space is denied. But one should be able to allow it.
This way, the options are fixed for any file. Would it be desirable to have different options for different kind of files?
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: http://tech.yipit.com/2011/11/16/183772396/.