Autosquash makes it quicker and easier to squash or fixup commits during an
interactive rebase. It can be enabled for each rebase using `git rebase -i
--autosquash`, but it's easier to turn it on by default.
Say I have this history:
$ git log --oneline
aaa1111 A first commit
bbb2222 A second commit
ccc3333 A third commit
I make another change that I already know should be squashed into "A
second commit". I can do this:
$ git add .
$ git commit --squash bbb2222
[my-branch ddd4444] squash! A second commit
Then when I rebase:
$ git rebase -i origin/my-branch
The interactive rebase list will be set up ready to squash:
pick aaa1111 A first commit
pick bbb2222 A second commit
squash ddd4444 squash! A second commit
pick ccc3333 A third commit
Since it's unlikely that anyone will be writing a commit message that begins
`squash!` or `fixup!` when they don't want this behaviour, and the user
still has a chance to review what's going to happen with the rebase, it's
safe to have it always turned on.
[vim-plug](https://github.com/junegunn/vim-plug) has a number of
advantages over Vundle:
* Installs and updates plugins very quickly in parallel
* Can lock plugins at versions/tags
* Can rollbacks updates (useful if a plugin breaks) and take/reload
snapshots of current state
* Optionally lazily-load plugins when their relevant command is invoked
* Execute post-update hooks for plugins with compiled extensions, etc.
vim-plug uses a DSL very close to Vundle (simplest form is `Plug` vs.
`Plugin`), and here it is set to continue to use the same plugin
location that Vundle was using before.
After updating, users will need to
1. Rename `Plugin` lines in `.vimrc.bundles.local` to use `Plug`
2. Run `:PlugInstall` (the post-up hook does this)
* 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`.
* 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.
`Rnavcommand` has been removed from rails.vim. These commands don't work
if you are using a recent version of the plugin. Users who want to
regain this functionality can do it through projections.
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]: 01cc928672/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 d7f194f94e
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-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`.
