It's not very useful to be dropped into the middle of your diff when
opening a new commit. This change prevents cursor position from being
restored for the `gitcommit` filetype.
I've had this in [my own dotfiles] for a while now, and really like
having the separation of what I consider to be code/configuration from
what to me feels more like a Gemfile, in that it lists out all of the
external dependencies in a single place.
[my own dotfiles](https://github.com/calebthompson/dotfiles/blob/master/vim/vimrc.bundles.symlink)
* Awesomer vundle integration:
* Refactor .vimrc and .vimrc.bundles to support standalone
BundleInstall.
* Install vim bundles as part of install.sh without sourcing the
normal vimrc, which prevents error messages from uninstalled
plugins referenced in the main vimrc.
dotfiles[master]/
↪ git submodule init
No submodule mapping found in .gitmodules for path 'vim/bundle/ctags.vim'
Git requires a `.gitmodules` file for submodules, but these aren’t
needed as `vundle` handles finding and cloning vim plugins.
There’s also not really any benefit to locking down a version as vim
plugins don’t have a standardized versioning system. Many don’t have
version numbers at all.
I've added a `.gitkeep` file, which is something I generally don’t like
having, but we need to have the directory around for vundle. I’d be up
for removing that and creating the directory in `install.sh`. Thoughts?
* Fixes an issue where tab completing specs that start with the same
words(s) makes tab completion freak out and stop working.
* The con is that we'll see "_spec.rb" in the output, like:
```zsh
$ rspec spec/models/
models/calendar_spec.rb
models/event_closer_spec.rb
...
```
vim-ruby is where Vim's support for Ruby comes from - file type
detection, syntax highlighting, etc. Vim bundles vim-ruby, but the
GitHub project is always ahead of what's released with Vim.
@jferris:
This has the effect that Git will never implicitly do a merge commit,
including while doing git pull. If I'm unexpectedly out of sync when I
git pull, I get this message:
> fatal: Not possible to fast-forward, aborting.
At that point, I know that I've forgotten to do something in my normal
workflow, and I retrace my steps.
@gylaz:
I like the value of seeing a failure message if a pull (or just merge)
fails due to not being able to get fast-forwarded. Then I can look to
see whose changes went out, that I may have not expected to be there.
Includes features such as:
* `:Bundle`, which wraps `bundle`.
* An internalized version of `bundle open`: `:Bopen` (and `:Bsplit`,
`:Btabedit`, etc.).
* `'path'` and `'tags'` are automatically altered to include all gems
from your bundle. (Generate those tags with
[gem-ctags](https://github.com/tpope/gem-ctags)!)
* Highlight Bundler keywords in `Gemfile`.
* Support for `gf` in `Gemfile.lock`, plus syntax highlighting that
distinguishes between installed and missing gems.
Having this file be sourced last allows user to
overwrite the configs in `.vimrc` without having to modify it.
* fixed file's path to work with `filereadable`
With arguments, g acts like git.
Without arguments, it runs `git status`.
* Source functions/* after loading ZSH completion so `compdef` is available to g
alias
https://github.com/ggreer/the_silver_searcher
* ag is faster than ack
* ag searches all files by default (but still ignores gitignored files). This
removes the need for ack's `--type-add=` options.
* The command is 33% shorter than ack!
Most tools look for $VISUAL before $EDITOR, and we tend to want that
anyway. This allows people to customize the two, for example using GUI
vim for $VISUAL and normal vim for $EDITOR, or more extreme: `ex -v` for
$VISUAL and `ex` for $EDITOR.
* Use a regular alias to make `s` short for `rspec`
* Use an `rspec` shell function to route to zeus when appropriate
* Removes confusion from `s` working differently than `rspec`
* Removes need to use a special alias to get zeus working
staging:
staging console
staging migrate
staging process
staging open
watch staging ps
staging tail
production:
production backup
production console
production migrate
production open
watch production ps
production tail
load-backup-into:
load-backup-into staging
load-backup-into development
Notes on the last command:
* Copy latest production database backup into development database using
preferred pgbackups + pg_restore method recommended by Heroku.
* Do not assume local development database name.
* Get local database name from config/database.yml.
* This did not previously exist in dotfiles.
Supporting change for these commands:
* Add ~/.bin to the PATH.
https://github.com/thoughtbot/dotfiles/pull/76
I've been experimenting with a workflow where I only run long-running
processes in tmux. Examples:
zeus start
foreman start
rake
tmux (or screen) are good at that: maintaining a long-running process
across shell sessions.
Instead of opening another tmux pane for vim and another for git
commands, Rails generators, test runs, etc., I do all of that outside of
tmux in my normal shell window. Those are all targeted, quick, actions.
They are what I am doing *right now*. It's my workspace.
While experimenting with this process, I noticed, I do jump into tmux
more often. Therefore, I wanted a shorter command for attaching to the
tmux session with the same name as the current directory.
