Add support for prepare-commit-msg hooks

[siwica]

I want to modify the default commit message a user sees when opening the commit message editor. Specifically I want to replace some placeholder in the commit-template with a string extracted from the current branch name and display the resulting text to the user without modifying the original commit template file.

Can this be done using overcommit and if so how and using which hook? pre_commit or prepare_commit_msg?

[trotzig]

Would this help? https://robots.thoughtbot.com/better-commit-messages-with-a-gitmessage-template

[sds]

Hey @siwica,

You are right that a prepare-commit-msg hook is the correct way to go here since you want to pre-populate a commit message with dynamic content before allowing the user to edit the commit message.

Overcommit does not yet support prepare-commit-msg hooks, but we'd happily accept a pull request adding support!

[siwica]

I might take a look at it, if I find some time. Haven't done anything in Ruby for quite a while though.

Could you shortly outline what would need to be done in order to add support for prepare-commit-msg hooks?

[sds]

You can see what went into adding support for pre-rebase hooks in #165 for a general example.

According to the prepare-commit-msg documentation, it will need to support one to three arguments, so you'll want to expose helpers for accessing these arguments in the Overcommit::HookContext::PrepareCommitMsg class you will create.

The Overcommit::HookContext::PrepareCommitMsg class you create will also need to provide a way to edit the commit message, similar to the Overcommit::HookContext::CommitMsg class.

[siwica]

Alright, thank you!

Two questions on conventions:

• What should a helper return when an argument can only be one out of a finite number of options (in my case: message, template, squash or commit). Return the raw string 'message', or rather a symbol :message?
• How should a helper behave if an argument is not set (prepare-commit-msg takes a variable number of arguments) and is thus not available? Raise an error or return nil?

[sds]

Sorry for the delay in response, @siwica.

For the first question, since there are a finite number of options a symbol seems appropriate. Another approach however is to instead expose methods like message?, template?, squash?, or commit? which indicate which type we are dealing with. At the end of the day the former seems simpler than the latter, and just as powerful.

For the second question, the type from the first argument should be used by hook authors to dictate whether other arguments can be queried. For example, we could define a template_file method which raises an exception if the type is not template.

Hope this helps.

[dcluna]

@siwica I had the same need myself, and I used a custom post-checkout hook to write a commit.template file. I took the time today to write it as a Overcommit hook, and you can see the result here.

@sds If you think this branch is something that could be merged, please let me know so I can open a PR.

[sds]

Implemented in #520