2011-03-24 13:14:28 -04:00
|
|
|
thoughtbot dotfiles
|
|
|
|
===================
|
|
|
|
|
2012-10-21 15:10:47 -07:00
|
|
|
Requirements
|
|
|
|
------------
|
|
|
|
|
2014-02-07 23:30:11 -08:00
|
|
|
Set zsh as your login shell:
|
2012-10-21 15:10:47 -07:00
|
|
|
|
2014-02-07 23:30:11 -08:00
|
|
|
chsh -s $(which zsh)
|
2012-10-21 15:10:47 -07:00
|
|
|
|
2011-03-24 13:14:28 -04:00
|
|
|
Install
|
|
|
|
-------
|
|
|
|
|
2013-03-03 21:13:16 -08:00
|
|
|
Clone onto your laptop:
|
2011-03-24 13:14:28 -04:00
|
|
|
|
2013-03-03 21:13:16 -08:00
|
|
|
git clone git://github.com/thoughtbot/dotfiles.git
|
|
|
|
|
|
|
|
(Or, [fork and keep your fork
|
2013-11-28 12:01:59 -08:00
|
|
|
updated](http://robots.thoughtbot.com/keeping-a-github-fork-updated)).
|
2013-03-03 21:13:16 -08:00
|
|
|
|
2014-01-23 12:55:14 -06:00
|
|
|
Install [rcm](https://github.com/thoughtbot/rcm):
|
2014-01-10 16:05:21 -05:00
|
|
|
|
2014-10-17 20:57:53 -04:00
|
|
|
brew tap thoughtbot/formulae
|
|
|
|
brew install rcm
|
2014-01-10 16:05:21 -05:00
|
|
|
|
2014-07-24 11:15:23 -04:00
|
|
|
Install the dotfiles:
|
2011-12-04 18:22:58 -05:00
|
|
|
|
2014-07-24 11:15:23 -04:00
|
|
|
env RCRC=$HOME/dotfiles/rcrc rcup
|
2013-10-11 15:07:51 +02:00
|
|
|
|
2014-07-24 11:15:23 -04:00
|
|
|
This command will create symlinks for config files in your home directory.
|
|
|
|
Setting the `RCRC` environment variable tells `rcup` to use standard
|
|
|
|
configuration options:
|
|
|
|
|
2014-12-02 21:01:54 -08:00
|
|
|
* Exclude the `README.md` and `LICENSE` files, which are part of
|
2014-07-24 11:15:23 -04:00
|
|
|
the `dotfiles` repository but do not need to be symlinked in.
|
|
|
|
* Give precedence to personal overrides which by default are placed in
|
|
|
|
`~/dotfiles-local`
|
2011-03-24 13:14:28 -04:00
|
|
|
|
2013-10-11 15:07:51 +02:00
|
|
|
You can safely run `rcup` multiple times to update:
|
2011-03-24 13:14:28 -04:00
|
|
|
|
2013-10-11 15:07:51 +02:00
|
|
|
rcup
|
2011-08-10 11:32:44 -03:00
|
|
|
|
2012-10-21 15:10:47 -07:00
|
|
|
Make your own customizations
|
|
|
|
----------------------------
|
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
Put your customizations in dotfiles appended with `.local`:
|
2012-10-21 15:10:47 -07:00
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
* `~/.aliases.local`
|
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.
2014-09-04 14:48:20 -07:00
|
|
|
* `~/.git_template.local/*`
|
2013-07-08 22:09:44 -07:00
|
|
|
* `~/.gitconfig.local`
|
2013-07-22 22:17:02 -06:00
|
|
|
* `~/.gvimrc.local`
|
2014-07-24 11:15:23 -04:00
|
|
|
* `~/.psqlrc.local` (we supply a blank `.psqlrc.local` to prevent `psql` from
|
|
|
|
throwing an error, but you should overwrite the file with your own copy)
|
2013-07-22 16:42:38 -06:00
|
|
|
* `~/.tmux.conf.local`
|
2013-07-22 22:17:02 -06:00
|
|
|
* `~/.vimrc.local`
|
2013-08-03 10:10:51 -04:00
|
|
|
* `~/.vimrc.bundles.local`
|
2014-07-27 22:54:36 -04:00
|
|
|
* `~/.zshenv.local`
|
2013-07-22 16:42:38 -06:00
|
|
|
* `~/.zshrc.local`
|
2014-07-22 16:51:20 +02:00
|
|
|
* `~/.zsh/configs/*`
|
2011-03-24 13:35:49 -04:00
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
For example, your `~/.aliases.local` might look like this:
|
2011-12-07 18:35:29 -05:00
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
# Productivity
|
|
|
|
alias todo='$EDITOR ~/.todo'
|
2012-10-21 15:10:47 -07:00
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
Your `~/.gitconfig.local` might look like this:
|
2012-10-21 15:10:47 -07:00
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
[alias]
|
|
|
|
l = log --pretty=colored
|
|
|
|
[pretty]
|
|
|
|
colored = format:%Cred%h%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset
|
|
|
|
[user]
|
|
|
|
name = Dan Croak
|
|
|
|
email = dan@thoughtbot.com
|
2011-12-07 18:35:29 -05:00
|
|
|
|
2015-03-12 14:37:24 -07:00
|
|
|
Your `~/.vimrc.local` might look like this:
|
|
|
|
|
|
|
|
" Color scheme
|
|
|
|
colorscheme github
|
|
|
|
highlight NonText guibg=#060606
|
|
|
|
highlight Folded guibg=#0A0A0A guifg=#9090D0
|
|
|
|
|
2014-07-27 22:54:36 -04:00
|
|
|
Your `~/.zshenv.local` might look like this:
|
|
|
|
|
|
|
|
# load pyenv if available
|
|
|
|
if which pyenv &>/dev/null ; then
|
|
|
|
eval "$(pyenv init -)"
|
|
|
|
fi
|
|
|
|
|
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.
2014-09-04 14:48:20 -07:00
|
|
|
To extend your `git` hooks, create executable scripts in
|
|
|
|
`~/.git_template.local/hooks/*` files.
|
|
|
|
|
2013-07-08 22:09:44 -07:00
|
|
|
Your `~/.zshrc.local` might look like this:
|
2011-12-07 18:35:29 -05:00
|
|
|
|
|
|
|
# recommended by brew doctor
|
|
|
|
export PATH="/usr/local/bin:/usr/local/sbin:$PATH"
|
|
|
|
|
2013-08-03 10:10:51 -04:00
|
|
|
Your `~/.vimrc.bundles.local` might look like this:
|
|
|
|
|
2015-05-12 11:19:11 -03:00
|
|
|
Plug 'Lokaltog/vim-powerline'
|
|
|
|
Plug 'stephenmckinney/vim-solarized-powerline'
|
2013-08-03 10:10:51 -04:00
|
|
|
|
2014-07-22 16:51:20 +02:00
|
|
|
zsh Configurations
|
|
|
|
------------------
|
|
|
|
|
|
|
|
Additional zsh configuration can go under the `~/.zsh/configs` directory. This
|
|
|
|
has two special subdirectories: `pre` for files that must be loaded first, and
|
|
|
|
`post` for files that must be loaded last.
|
|
|
|
|
|
|
|
For example, `~/.zsh/configs/pre/virtualenv` makes use of various shell
|
|
|
|
features which may be affected by your settings, so load it first:
|
|
|
|
|
|
|
|
# Load the virtualenv wrapper
|
|
|
|
. /usr/local/bin/virtualenvwrapper.sh
|
|
|
|
|
|
|
|
Setting a key binding can happen in `~/.zsh/configs/keys`:
|
|
|
|
|
|
|
|
# Grep anywhere with ^G
|
|
|
|
bindkey -s '^G' ' | grep '
|
|
|
|
|
|
|
|
Some changes, like `chpwd`, must happen in `~/.zsh/configs/post/chpwd`:
|
|
|
|
|
|
|
|
# Show the entries in a directory whenever you cd in
|
|
|
|
function chpwd {
|
|
|
|
ls
|
|
|
|
}
|
|
|
|
|
|
|
|
This directory is handy for combining dotfiles from multiple teams; one team
|
|
|
|
can add the `virtualenv` file, another `keys`, and a third `chpwd`.
|
|
|
|
|
|
|
|
The `~/.zshrc.local` is loaded after `~/.zsh/configs`.
|
|
|
|
|
|
|
|
vim Configurations
|
|
|
|
------------------
|
|
|
|
|
|
|
|
Similarly to the zsh configuration directory as described above, vim
|
|
|
|
automatically loads all files in the `~/.vim/plugin` directory. This does not
|
|
|
|
have the same `pre` or `post` subdirectory support that our `zshrc` has.
|
|
|
|
|
|
|
|
This is an example `~/.vim/plugin/c.vim`. It is loaded every time vim starts,
|
|
|
|
regardless of the file name:
|
|
|
|
|
|
|
|
# Indent C programs according to BSD style(9)
|
|
|
|
set cinoptions=:0,t0,+4,(4
|
|
|
|
autocmd BufNewFile,BufRead *.[ch] setlocal sw=0 ts=8 noet
|
|
|
|
|
2013-03-03 21:13:16 -08:00
|
|
|
What's in it?
|
|
|
|
-------------
|
|
|
|
|
|
|
|
[vim](http://www.vim.org/) configuration:
|
|
|
|
|
|
|
|
* [Ctrl-P](https://github.com/kien/ctrlp.vim) for fuzzy file/buffer/tag finding.
|
|
|
|
* [Rails.vim](https://github.com/tpope/vim-rails) for enhanced navigation of
|
|
|
|
Rails file structure via `gf` and `:A` (alternate), `:Rextract` partials,
|
|
|
|
`:Rinvert` migrations, etc.
|
|
|
|
* Run [RSpec](https://www.relishapp.com/rspec) specs from vim.
|
|
|
|
* Set `<leader>` to a single space.
|
|
|
|
* Switch between the last two files with space-space.
|
|
|
|
* Syntax highlighting for CoffeeScript, Textile, Cucumber, Haml, Markdown, and
|
|
|
|
HTML.
|
|
|
|
* Use [Ag](https://github.com/ggreer/the_silver_searcher) instead of Grep when
|
|
|
|
available.
|
|
|
|
* Use [Exuberant Ctags](http://ctags.sourceforge.net/) for tab completion.
|
2014-09-30 09:31:48 -07:00
|
|
|
* Use [vim-mkdir](https://github.com/pbrisbin/vim-mkdir) for automatically
|
|
|
|
creating non-existing directories before writing the buffer.
|
2015-02-18 21:29:50 -05:00
|
|
|
* Use [vim-plug](https://github.com/junegunn/vim-plug) to manage plugins.
|
2013-03-03 21:13:16 -08:00
|
|
|
|
2013-11-28 12:01:59 -08:00
|
|
|
[tmux](http://robots.thoughtbot.com/a-tmux-crash-course)
|
2013-03-03 21:13:16 -08:00
|
|
|
configuration:
|
|
|
|
|
|
|
|
* Improve color resolution.
|
|
|
|
* Remove administrative debris (session name, hostname, time) in status bar.
|
|
|
|
* Set prefix to `Ctrl+a` (like GNU screen).
|
|
|
|
* Soften status bar color from harsh green to light gray.
|
|
|
|
|
|
|
|
[git](http://git-scm.com/) configuration:
|
|
|
|
|
|
|
|
* Adds a `create-branch` alias to create feature branches.
|
|
|
|
* Adds a `delete-branch` alias to delete feature branches.
|
|
|
|
* Adds a `merge-branch` alias to merge feature branches into master.
|
2013-04-14 10:57:44 -07:00
|
|
|
* Adds an `up` alias to fetch and rebase `origin/master` into the feature
|
|
|
|
branch. Use `git up -i` for interactive rebases.
|
2014-07-18 09:58:50 -04:00
|
|
|
* Adds `post-{checkout,commit,merge}` hooks to re-index your ctags.
|
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.
2014-09-04 14:48:20 -07:00
|
|
|
* Adds `pre-commit` and `prepare-commit-msg` stubs that delegate to your local
|
|
|
|
config.
|
2013-03-03 21:13:16 -08:00
|
|
|
|
2013-09-10 20:20:35 -07:00
|
|
|
[Ruby](https://www.ruby-lang.org/en/) configuration:
|
|
|
|
|
|
|
|
* Add trusted binstubs to the `PATH`.
|
|
|
|
* Load rbenv into the shell, adding shims onto our `PATH`.
|
|
|
|
|
2013-03-03 21:13:16 -08:00
|
|
|
Shell aliases and scripts:
|
|
|
|
|
|
|
|
* `b` for `bundle`.
|
|
|
|
* `g` with no arguments is `git status` and with arguments acts like `git`.
|
|
|
|
* `git-churn` to show churn for the files changed in the branch.
|
|
|
|
* `m` for `rake db:migrate && rake db:rollback && rake db:migrate && rake db:test:prepare`.
|
|
|
|
* `mcd` to make a directory and change into it.
|
|
|
|
* `replace foo bar **/*.rb` to find and replace within a given list of files.
|
|
|
|
* `rk` for `rake`.
|
|
|
|
* `tat` to attach to tmux session named the same as the current directory.
|
|
|
|
* `v` for `$VISUAL`.
|
2012-09-14 11:22:33 -07:00
|
|
|
|
2015-03-09 13:48:23 -04:00
|
|
|
Thanks
|
|
|
|
------
|
2012-09-14 11:22:33 -07:00
|
|
|
|
2013-03-06 11:01:26 -08:00
|
|
|
Thank you, [contributors](https://github.com/thoughtbot/dotfiles/contributors)!
|
2013-06-18 16:47:01 -07:00
|
|
|
Also, thank you to Corey Haines, Gary Bernhardt, and others for sharing your
|
|
|
|
dotfiles and other shell scripts from which we derived inspiration for items
|
|
|
|
in this project.
|
2012-09-14 11:22:33 -07:00
|
|
|
|
2015-03-09 13:48:23 -04:00
|
|
|
License
|
|
|
|
-------
|
|
|
|
|
|
|
|
dotfiles is copyright © 2009-2015 thoughtbot. It is free software, and may be
|
|
|
|
redistributed under the terms specified in the [`LICENSE`] file.
|
|
|
|
|
|
|
|
[`LICENSE`]: /LICENSE
|
2012-09-14 11:22:33 -07:00
|
|
|
|
2015-03-09 13:48:23 -04:00
|
|
|
About thoughtbot
|
|
|
|
----------------
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
dotfiles is maintained and funded by thoughtbot, inc.
|
2012-09-14 11:22:33 -07:00
|
|
|
The names and logos for thoughtbot are trademarks of thoughtbot, inc.
|
|
|
|
|
2015-03-09 13:48:23 -04:00
|
|
|
We love open source software!
|
|
|
|
See [our other projects][community].
|
|
|
|
We are [available for hire][hire].
|
|
|
|
|
|
|
|
[community]: https://thoughtbot.com/community?utm_source=github
|
|
|
|
[hire]: https://thoughtbot.com/hire-us?utm_source=github
|