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 cpan.org.

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:

http://git.661346.n2.nabble.com/pre-rebase-safety-hook-td1614613.html

http://git.apache.org/xmlbeans.git/hooks/pre-rebase.sample

http://www.mentby.com/Group/git/rfc-pre-rebase-refuse-to-rewrite-commits-that-are-reachable-from-upstream.html

http://git.661346.n2.nabble.com/RFD-Rewriting-safety-warn-before-when-rewriting-published-history-td7254708.html

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 https://github.com/schacon/githooks.

In CheckAcls implement DENY for ACL operations

Along the lines of NFSv4 ACLs (http://tools.ietf.org/html/rfc5661#section-6). I'm thinking about prefixing the what component with a '!'.

Implement equivalents for the SVN::Hooks plugins

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.

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.

CheckLog should check the footer of the commit log message

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

Require Signed-off-by lines (https://github.com/icefox/git-hooks/blob/master/git_hooks/commit-msg/signed-off-by)

Duplicate Signed-off-by lines (https://github.com/icefox/git-hooks/blob/master/contrib/commit-msg/duplicate-signedoffby)

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: http://tech.yipit.com/2011/11/16/183772396/.