High-Level Description
This feature is meant to give some hook script functionality for RBTools through a new command, repo-hook. Specifically, the repo-hook command allows users to call RBTools based pre-receive and post-receive hook script functionality from their own hook scripts.
The pre-receive functionality is focused on checking commits in the incoming push for review request IDs, and possibly cancelling the push if criteria are not met. This criteria depends on whether certain options are activated or left default (--dont-require-review-requests and --allow-unapproved-push). By default, the push will be cancelled if there are any commits without review requests, or if any review requests are not approved.
The post-receive functionality is based on closing any review requests referenced in commit messages in the current push. In this instance, a push cannot be cancelled, and warnings will be raised if there are commits with no review requests.
Initial Plans
Initial plans for this command were to have hook script functionality for multiple SCM systems, specifically starting with Git, Mercurial, and Subversion. At this point, only functionality for Git has been implemented, with skeleton code and empty classes being implemented for SVN and Mercurial.
How the Code Works Together
This functionality is performed by a RepoHook Command class. This class will perform all the SCM agnostic logic of the hook scripts. From this class, depending on the --repo-type option specified (again, currently only Git is an option), a SCMRepositoryHooks subclass representing the repository in --repo-type will be called to provide RepoHook with the information it needs in order to work, while performing all SCM specific code within it's own class.
Next Steps
Next steps would involve getting code reviews to confirm that the Git and RepoHook logic are bug-free, as well as implementing the SVN and Mercurial logic in their corresponding classes to allow more variety of SCMs. 
Additionally, outside of initial scope, other hook types could be implemented. One that would prove useful is pre-commit functionality to ensure that a review request ID is included in the commit message. This would help avoid issues with using the pre-receive functionality, as the only issue that could arise would be that a review request is not approved.

Have done local testing with a local Git repository on my machine containing pre-receive and post-receive hook scripts that call the rbt repo-hook command to ensure that the code works.
Have created a suite of tests to test various options and how they would cause the RepoHook command to react. This includes testing all variations of --repo-type and --hook-type (allowed, un-implemented, no variant selected, and default value), default and specified server options, regex flag options, and both variations of all other toggle-able options.