* Every time I pull updates from this repo into my own dotfiles, I have to reconfigure my preferred theme (solarized) * Seems like there is not a majority or plurality of thoughbotters using a single colorscheme * Easiest to just not specify a colorscheme * See https://forum.upcase.com/t/why-is-the-default-vim-theme-on-dotfiles-is-github/4232
I am constantly forgetting that I can't use `ctrl-p` to open `.travis.yml` or any other file with a leading `.`. This change comes about after some discussion in general on how to handle this. Passing `--hidden` to the `ag` command allows it to find files with a leading `.`. Unfortunately, this also includes the content of your `.git` directory. To overcome this, we add `/.git/` to `agignore`.
It is not needed - see http://vimdoc.sourceforge.net/htmldoc/options.html#'nocompatible'; (or see :help 'cp')
* Lists all remote branches * Sorts by last commit date, descending * Shows how long the branch has been around * Shows last commit author ``` $ git branches 6 days ago Dan Croak origin/HEAD 6 days ago Dan Croak origin/master 5 months ago Dan Croak origin/dc-rbenv-zsh 6 months ago Sean Doyle origin/sd-nvm-path 6 months ago Tute Costa origin/vim-multiple-cursors 7 months ago Sean Doyle origin/sd-vundle 8 months ago Sean Griffin origin/sg-disable-spring 9 months ago Mike Burns origin/mb-experimental-tag ```
When within a git repository, doing a tab-autocomplete on a command results with the command becoming unreadable. The command still works but this is pretty annoying visually. Basically I 1. Navigate to a directory with a git repository in it. The prompt indicates the current branch properly 2. Next, type `git -` and hit tab The prompt now shows only part of branch's name with the first suggestion appended. After googling a bit I stumbled upon several pages describing a similar problem (most useful to me was http://stackoverflow.com/questions/23740862/issues-with-zsh-prompt). The culprit seems to be the git_prompt_info function escaping the `$current_branch` variable as if it is a color. As a result zsh is confused where the cursor is. After "unescaping" the variable everything seems to work fine. Using zsh 5.0.7 (x86_64-apple-darwin13.4.0).
* Silver searcher or ag was filtering out any directory that had a .DS_STORE file. Any directory that has a .DS_STORE file in it is being ignored by ag and therefor does not show up in the ctrlp fuzzy finder either. * Removing the * from before .DS_STORE in the gitignore file still prevents .DS_STORE files from being checked into source control and stops ag from filtering out the directory. I am not sure if this is a bug with silver_searcher or what
A few aliases contain references to environment variables, but were defined using double quotes. This caused zsh to interpolate the value of those variables when the alias was defined instead of when it was executed. In particular, any change to `PATH` (or `EDITOR` or `VISUAL`) in `.zshrc.local`, which is sourced after `.aliases`, would not be reflected in these aliases. This commit defines these aliases using single quotes so that the environment variables are evaluated when the alias is executed.
The existing script would fail if run from within tmux as the default behavior would cause a nested tmux session which is bad. This update detects if the current context is within tmux and properly handles this by creating a detached session and switching to it as needed. The idea with this is for tat to behave correctly regardless of context, which I believe this update achieves. Existing users and workflows all work identically, but now this adds support for a workflow that remains within tmux at all times. I prefer to remain within tmux all the time, rather than falling back to the shell, navigating to another directory, and then creating the session from there. With this update, I split a pane in the current tmux window, navigate to the directory for the new session, and use `tat` to open (or attach) to the new-session without ever leaving tmux. I actually [have a binding that I use for this], `C-b` (I am "breaking" out a new session), that is mapped to `bind C-b send-keys 'tat && exit' 'C-m'`, which also cleans up the pane. The reason for wanting this workflow is I am pretty strict about keeping a tmux session focused to a single project (~ maps to a git repo). I regularly want to reference another app and will use this workflow to quickly open that project in a new session. A "detached" session is one which has no clients attached. [From the man page entry] for `new-session`: `The new session is attached to the current terminal unless -d is given.` This essentially creates it in the background, preventing nesting. Then the script can attach the current client using the `switch-client` command. [have a binding that I use for this]: https://github.com/christoomey/dotfiles/blob/01cc928672ea857aafbe904968010baabfe6aebb/tmux/tmux.conf#L89 [From the man page entry]: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1
For users who had not overridden the `pre-commit` or `prepare-commit-msg` Git hooks, they would see `git commit` hang, with nothing happening. The command would exit without going to their editor. The bug was introduced in d7f194f and the fix is to return a 0 exit code when the override is not present.
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.
* 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
Some homebrew formulae, (e.g. [RabbitMQ]) link binaries here. : https://github.com/Homebrew/homebrew/blob/master/Library/Formula/rabbitmq.rb
The body of a git commit message is conventionally (, ) wrapped at 72 characters. This commit adjusts .vimrc to automatically wrap the body of git commit messages at 72 characters. : http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message : http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Not seeing these can be problematic, since you won't know what broke your code on the day that one of them sneaks in. Here's a few other common characters people use for this: https://github.com/search?utf8=%E2%9C%93&q=nbsp%3A+extension%3A.vimrc&type=Code&ref=searchresults
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).