chore(commit message): use commitplease to validate commit messages

[alisianoi]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Outsource commit message validation, automate installing as git commit-msg hook.

What is the current behavior? (You can also link to an open issue here)

There is a validate-commit-msg.js that can be called manually or linked as a git hook via init-repo.sh.

What is the new behavior (if this is a feature change)?

A dependency on commitplease, an external npm module, to do the commit message style checks.

Does this PR introduce a breaking change?

No

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:

Pros of using:

1. No need to manually run validate-commit-msg.js or init-repo.sh
2. Automatically installs with npm install and runs with git commit
3. When the commit message is not valid, provides a specific reason why

How to try out:

git checkout commitplease
mv .git/hooks/commit-msg .git/hooks/commit-msg.old
npm install

Now try to commit some changes with valid/invalid commit messages.

How to go back:

git checkout master
mv .git/hooks/commit-msg.old .git/hooks/commit-msg

Disclaimer: I am contributing to commitplease as part of the Google Summer of Code project for students.

[gkalpak]

I am not sure we want to impose this to all contributors. We do support commitizen to help people format their messages, but failing when the are not following the conventions is a bit harsh I think.

[jzaefferer]

I haven't yet looked at commitizen, but in regards to, "but failing when the are not following the conventions is a bit harsh I think.", that's a fair concern. I originally developed this module for jQuery Foundation projects, where its been in use for more than 2 years (different validation rules, otherwise same approach). As far as I know, it has been working pretty well. Since the tool provides immediate feedback, its easy to try again and fix the issue (unlike a CI feedback loop, where there's often several minutes between making a change and getting feedback).

You could give it a try. If there are issues, we can help improve the feedback. As kind of a last resort, you could set nohook: false, to prevent automatically installing the hook. Then you'd have to install the hook manually (or put that back into init-repo.sh). Would still be an improvement of the current custom script, since that same approach can be used in other repos.

[alisianoi]

Here are a few problems with commitizen that I found:

1. Leaving all fields blank (i.e. pressing Enter all the time) creates an ill-formatted commit message.
2. Starting scope with the dollar-sign "$", as recommended by the question text, creates empty scope.
3. Could not find an obvious way to create lists in the commit message (i.e. insert a line break). Both Ctrl+Enter and Shift+Enter skip to the next question like Enter. Maybe there is another shorcut?

[petebacondarwin]

Actually I like the look of this. We can starts lines with WIP for knocking up non-normalised commits. It even handles revert commits.

Let's install it and try it for a bit. If it is not working or too annoying then we can always remove it again.

@all3fox is there a clean "uninstall" of this module?

[alisianoi]

@petebacondarwin, glad to hear that! Here is a clean uninstall procedure:

1. remove the git hook rm .git/hooks/commit-msg
2. uninstall the module npm uninstall commitplease
3. cleanup package.json (changes made by this PR)

If you find any bugs/annoyances, do not hesitate to report them here or in this PR!

As a side note, here are ways to do dirty commits:

1. WIP, wip or Wip at the start of commit message
2. fixup! or squash! at the start of the message. These are part of git automatic squashing
3. git commit --no-verify which skips the git hook and allows to commit with any non-empty message

[petebacondarwin]

Is it not possible to have a postuninstall hook in the commitplease module that removes the hook?

[petebacondarwin]

I tried this out and it doesn't work with GUIs like SmartGit - primarily because, I believe, that the GUI doesn't know what version of node is needed and where to find that node.

[alisianoi]

@petebacondarwin about the automatic git hook uninstall:

There used to be a problem with commitplease 2.5.0 and there still is a problem with npm 3.x

We have solved our problem by releasing commitplease 2.6.0 yesterday and now it works with npm 2.x. This PR got updated, the hook will be automatically uninstalled.

Unfortunately, the problem remains with npm 3.x. In fact, it looks like an npm problem: order of script execution and no script execution at all. So, with npm 3.x it is "better" to remove the hook manually for now.

I have also tried the postuninstall hook instead of the uninstall hook, as you suggested. For me both these hooks do not get triggered with npm 3.x, specifically npm 3.8.6 and npm 3.10.3

I will take a look at SmartGit now.

[alisianoi]

As for SmartGit, commitplease 2.6.0 worked just fine for me (no extra actions):

Update: I am running ArchLinux, please tell me if you are running Mac OS or Windows

[Narretz]

Here's an altenative PR that adds a manual check to the Travis CI_CHECKS job: #16097

the git hook is turned off.

This will provide feedback to contributors without getting in the way of doing some dirty commits. I trust committers who push directly to the repo to use correct commit messages ;) Most changes go through PRs anyway.