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-commithttps://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.
* Adding /usr/local/bin to path in `~/.zshenv` causes it to be in my path twice one right after the other. /usr/local/bin is already added to the path in the correct order on OSX Yosemite by the /etc/paths file.
* Remove /usr/local/bin from path export in zshenv
The glob used a modifier, but it was modifying a directory instead of a
glob that matched all the files in the directory. Add the missing `*` to
fix this.
Running `rcup` should remove any plugins that are no longer in use. For
instance, we recently replaced `rename.vim` with `eunuch`. `rcup`
installs the new plugin but does not clean up `rename` from the plugins
directory. The addition of `PluginClean!` does this (without
confirmation).
From the [Zsh manual](http://zsh.sourceforge.net/Intro/intro_3.html):
> '.zshenv' is sourced on all invocations of the shell, unless the -f option is
> set. It should contain commands to set the command search path, plus other
> important environment variables. `.zshenv' should not contain commands that
> produce output or assume the shell is attached to a tty.
Why is this important? [Alfred](http://www.alfredapp.com/) workflows run in
non-interactive shells. When the `$PATH` is set, or `rbenv` is initialized, in
`zshrc` instead of `zshenv`, those workflows will not use the correct Ruby
version and might not have access to certain bin files, such as those from
`$HOME/.bin/` or Homebrew.
Fugitive was updated to switch to horizontal diffs on narrow screens.
Everyone I've seen experience this behavior finds it disorienting. This
setting forces a vertical diff without users having to use different
shortcuts to enter diff mode.
Does what rename.vim does (`:Move` or `:Rename`) **plus**:
* Adds `:Unlink` or `:Remove` to delete the current buffer + file
* Adds `:Mkdir` (with no argument, create the current file's containing
directory)
* Adds `:SudoWrite` if you forget to edit a file as root
* Automatically chmods a file to `+x` if it starts with `#!`
* Tim Pope! ❤️
Just before loading `~/.zshrc.local`, load:
1. `~/.zsh/configs/pre/**/*`
2. `~/.zsh/configs/**/*` # excluding pre and post
3. `~/.zsh/configs/post/**/*`
About the zsh glob:
- `.`: only produce normal files.
- `-`: follow symlinks to their final file; skip any broken links.
- `N`: do not complain about zero matches.
Big ups to Pat Brisbin for finding `N`.
* Remove unnecessary `uniq`
* Look for tags in tmp/tags or .git/tags
* Send errors to /dev/null if the file(s) do not exist
See http://tbaggery.com/2011/08/08/effortless-ctags-with-git.html for an
explanation behind the reasoning for .git/tags.
I wanted to add my own customizations after reading @mike-burns' post on
[`psqlrc`](http://robots.thoughtbot.com/an-explained-psqlrc).
As a result of this change, `.psqlrc` requires that a `.psqlrc.local`
exist in the home folder because `psql` cannot do conditional sourcing
of files in the style that we use in other foundation dotfiles. Touching
the file to ensure it exists (even if blank) prevents `psql` from
exiting with an error if the user does not provide their own custom
configuration.
Additional changes:
* Updating the documentation with regard to which files get excluded.
Running `zg` adds words to the `spellfile`:
4f5a2edc33http://robots.thoughtbot.com/vim-spell-checking
Setting the spellfile keeps it out of its default location, `vim/spell`, which
would otherwise be inside thoughtbot/dotfiles. We don't necessarily want to
share the `spellfile` across the team.
This is for homebrew binaries to work.
Load `rbenv` after adding `$HOME/.bin` and `/usr/local/bin` to `PATH`, but
before adding project-specific binstubs.
Removal in deb7ee5948
was accidental.
Also, removes `vim/bundle` directory as it is no longer useful to us, since
`vundle` creates it when it needs to.
The Syntastic HTML linter will warn on propriety attributes. The
likelihood that you *accidentally* typed "ng-repeat" is low. Let's just
assume you know what you're doing and ignore warnings about "ng-*"
attributes.
* Switch order from "[git branch][pathname]" to "basename git branch %".
* Remove noisy brackets.
Example old:
[master][~/dev/thoughtbot/dotfiles]
Example new:
dotfiles dc-prompt %
With `shiftround` enabled, using `>>` will indent the line to the next
multiple of `shiftwidth`. This is useful when you are indenting
improperly indented code.
`:e some/non_existent_directory/new_file.txt` usually errors out because
the directory does not exist, but with `vim-mkdir` the non-existent
directory will be created automatically.