Add more Git hooks, delegate to .local convention

The `pre-commit` and `prepare-commit-msg` git hooks can be used
for some interesting things such as linting files.

For example, I need to format, vet, and lint Go files:

https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/pre-commit
https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/prepare-commit-msg

We've rejected Go-related pull requests to thoughtbot/dotfiles
due to not doing enough "official" Go work at the company.
This change helps me start with `.local` for now,
and then promote to "upstream" (thoughtbot/dotfiles) at some point
in the future if we do more "official" Go work.

I'm a believer in having linting done at VCS "commit time", either
locally in a pre-commit so I have a chance to fix things and not both my
teammates with linting issues, or at post-commit time via Hound comments
(also automated, but opportunity to ignore).

I've tried adding linting libraries to my editor, and found them too
slow, at least for Ruby. I've limited "editor-time" checking to just
syntax checking via Syntastic.

The downsides I see to adding linting to the test suite are:

* Style violations are not functional failures and logically shouldn't
  fail a build.
* Adding code coverage, linting, etc. to a test suite slows down the
  build.
* I only need to lint my diff (the commit), not the whole codebase, when I
  make changes.
* Style violations should not prevent a user-facing, production deploy.
* Adding linting to the test suite can slow that process down
  unnecessarily, particularly in continuous integration setups.

I see the appeal of linting in the test suite, particularly for
greenfield apps where we have total control, but I don't think it's a
practice that we can universally apply to our client projects who have
different deploy setups and existing codebases. So, I prefer the git
hooks + Hound approach as a pragmatic middle ground.
This commit is contained in:
Dan Croak 2014-09-04 14:48:20 -07:00
parent 782bcf7ddb
commit d7f194f94e
3 changed files with 14 additions and 1 deletions

View file

@ -46,6 +46,7 @@ Make your own customizations
Put your customizations in dotfiles appended with `.local`:
* `~/.aliases.local`
* `~/.git_template.local/*`
* `~/.gitconfig.local`
* `~/.gvimrc.local`
* `~/.psqlrc.local` (we supply a blank `.psqlrc.local` to prevent `psql` from
@ -79,6 +80,9 @@ Your `~/.zshenv.local` might look like this:
eval "$(pyenv init -)"
fi
To extend your `git` hooks, create executable scripts in
`~/.git_template.local/hooks/*` files.
Your `~/.zshrc.local` might look like this:
# recommended by brew doctor
@ -171,7 +175,8 @@ configuration:
* Adds an `up` alias to fetch and rebase `origin/master` into the feature
branch. Use `git up -i` for interactive rebases.
* Adds `post-{checkout,commit,merge}` hooks to re-index your ctags.
To extend your `git` hooks, create executable scripts in `~/.git_template.local/hooks/post-{commit,checkout,merge}`
* Adds `pre-commit` and `prepare-commit-msg` stubs that delegate to your local
config.
[Ruby](https://www.ruby-lang.org/en/) configuration:

4
git_template/hooks/pre-commit Executable file
View file

@ -0,0 +1,4 @@
#!/bin/sh
local_hook="$HOME"/.git_template.local/hooks/pre-commit
[ -f "$local_hook" ] && . "$local_hook"

View file

@ -0,0 +1,4 @@
#!/bin/sh
local_hook="$HOME"/.git_template.local/hooks/prepare-commit-msg
[ -f "$local_hook" ] && . "$local_hook"