@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.
* Set up Vundle in vimrc.
* Delete old copies of vim scripts.
* Bundles are automatically set up as referenced submodules.
* Ignore .netrwhist files given presence of submodules.
* Set up vundle in install script.
After you commit a bug fix to a feature branch, find out if the code
you changed to fix the bug is in files that change often:
git-churn
If the buggy code changes often, find smells and refactor them. Separate
the parts that change often from the parts that don't.
Conversely, avoid refactoring areas with low churn. Refactoring changes
code, and with each change, you risk introducing new bugs.
Example:
[feature-branch][~/dev/rails-app] churn
2 app/controllers/accepts_controller.rb
2 config/database.yml
4 app/helpers/application_helper.rb
4 config/application.rb
9 spec/models/user_spec.rb
9 spec/spec_helper.rb
12 spec/requests/dashboard_spec.rb
13 spec/models/feedback_spec.rb
19 app/models/feedback.rb
21 app/models/user.rb
