prepare pull request message hook

[nyarly]

By analogy to git's prepare-commit-message, it'd be great to be able to set up a prepare-pull-request-message as well. My specific use case is integrating with ticketing systems (e.g. Pivotal Tracker and Jira) which recognize ticket ids in commit and PR messages and automatically update the associated tickets. It's very handy to be able to have local configs and plug that information into the PR automatically.

(Respectfully, I see that the github PR templates were integrated into hub, and I'd've thought the .git/hooks approach would've been the right approach to that...)

[nyarly]

@mislav - just a ping to see if this is an acceptable feature. I'd prefer to get buy-in from a contributor before investing time in a PR.

[mislav]

@nyarly Sorry for the late reply! It's not a bad idea. How would the hook funcitonaly work exactly, i.e. when is it called, what are its input, and what would be its output? Thanks!

[nyarly]

Not to be too original:

Hooks are little scripts you can place in $GIT_DIR/hooks

This hook is invoked by hub pull-request right after preparing the default 
log message, and before the editor is started.

        It takes one to three parameters. The first is the name of the file that 
contains the commit log message. The second is the source of the commit 
message, and can be: message (if a -m or -F option was given); or commit, 
followed by a commit SHA-1

       If the exit status is non-zero, hub pull-request will abort.

       The purpose of the hook is to edit the message file in place. A non-zero
 exit means a failure of the hook and aborts the commit.

I note that git's docs don't guarantee that git init copies all the files in the GIT_TEMPLATE, but a quick test seems to confirm that it does, so .git/hooks/prepare-pull-request-message would be where it'd live.

[mdgreenfield]

I would recommend that if a repo has a PULL_REQUEST_TEMPLATE defined, hub should default to using that template.

Optionally, maybe, a .git/hooks/prepare-pull-request-message could be included somehow. Maybe the hook gets appended to the PULL_REQUEST_TEMPLATE or maybe there is some hub configuration that can be used to define precedence. I'm not sure what makes the most sense.

[jasonk]

I think there is some confusion about how git hooks work. This wouldn't be something that gets added to the message instead of (or in addition to) the PULL_REQUEST_TEMPLATE, so there isn't any need to define precedence.

This would work the same way the default git prepare-commit-msg hook works. It's not content to go into the message, but a script that gets run with the path to the file containing the message as an argument.

So, assuming the current workflow was something like this:

1. create $tempfile using PULL_REQUEST_TEMPLATE or default pull-request message
2. Run $EDITOR $tempfile
3. Read $tempfile and submit pull request

The new workflow would just add hooks around that process. To make it work like the default git prepare-commit-msg and commit-msg hooks, you would update that workflow like this:

1. create $tempfile using PULL_REQUEST_TEMPLATE or default pull-request message
2. Run .git/hooks/prepare-pull-request-msg $tempfile (if it exists)
3. Run $EDITOR $tempfile
4. Run .git/hooks/pull-request-msg $tempfile (if it exists)
5. Read $tempfile and submit pull request

It seems that hub already encapsulates the "build a message from a template and then launch your editor on it" logic in github/message_builder.go, so it seems like all you really need is a property in there for the type of message, and then something that could interject the "run hooks" steps as mentioned above. By passing in a message type (for example, passing pull-request for this particular use case) you could then look for prepare-<type>-msg and <type>-msg hooks in much the same way that git does. Then all you would need to do to add hooks support to any given command that lets you edit a file to produce a message would be to make sure that the appropriate type is being passed to it's MessageBuilder instance.

I may take a stab at a PR at some point, but I don't know go, so it probably wouldn't be any time soon..

[jasonk]

Shortly after writing that last comment it occurred to me that this could be done right now, just by wrapping your editor in a command that can invoke hooks.

So, if you don't want to wait for this to make it into hub...
https://gist.github.com/jasonk/69238f98d09ff8e381fd054abc0b5936

I thought about adding support for pull request templates, but there are so many different places they can be stored in the repo that it was too much work for a simple shell script..