MessageTemplate post-checkout hook

[dcluna]

This commit adds the MessageTemplate post-checkout hook, which, when correctly
configured, automatically generates a commit message
template
based on the branch name.

Groups captured in the branch_pattern regex can be used in replacement_text;
see the accompanying spec for details. Also, replacement_text can be a path to
a file, whose text will be processed following the same rules.

--

This may help with the request in #470.

[sds]

Hey @dcluna, thanks for sharing this PR. Apologies for not responding to your original request for feedback in #470.

Let me first say that I totally see the value in what you are trying to accomplish. Having the ability to customize the commit message template that appears when you commit is a useful feature, especially in organizations that value well-written commit messages.

However, I disagree with the approach taken here to accomplish the goal of customizable commit message templates.

First of all, the prepare-commit-msg hook is explicitly meant for this use case, so it seems odd to piggy-back on the post-checkout hook. Furthermore, using a post-checkout hook results in this code running every time your HEAD changes, rather than just at the time you are creating your commit. Lastly, a prepare-commit-msg hook would give more flexibility that what you currently have here, and be more extensible (for example, you could inspect the staged files and generate a template depending on which files were changed, which you can't do with a post-checkout since you haven't authored anything at that point).

What this implementation does is perfectly suitable for a single organization to use if it chooses, but I don't see it as extensible or general-purpose enough to be included by default in Overcommit.

The better long-term answer is to implement #470 so that arbitrarily-complex templates can be generated on an as-needed basis, rather than every time HEAD changes. This uses the existing tools provided by Git as intended, and also provides an entire platform for developers to build on top of, rather than a less-flexible solution limited to branch names and regex substitutions.

Hope that explains my position here. Would be more than happy to accept a pull request implementing #470! (which is not that much work—see my comment in the original thread)

[dcluna]

@sds Thanks for the kind words. If nobody beats me to it, I'll try to come up with the PR you suggested.