Suggest Alternate Resolution Strategy

[wycats]

I personally use a different resolution strategy for both migrations and bundler.

Bundler

1. As of sometime in 1.0, it should be fine to always run bundle install without running the check first. If the check is required, that's a bug. So if the Gemfile changes, it should be equally fast to run bundle install again.
2. If there is a conflict in Gemfile.lock, I propose the following resolution strategy:
   1. git checkout Gemfile.lock -- <older branch>
   2. bundle install
   3. this is because bundler already knows how to resolve conflicts between Gemfile and Gemfile.lock, and will properly handle all the edge-cases we know about

Migrations

For similar reasons, I propose the following resolution strategy for conflicts in schema.rb

1. git checkout db/schema.rb -- <older branch>
2. rake db:migrate
3. Again, rake db:migrate knows how to bring a schema.rb up to date with newer migrations

Is there any reason my thinking here is incorrect?

[tpope]

A no-op bundle install is slower than bundle check (6 seconds versus 3 seconds on the project sitting in front of me). I'd love to ditch it, but for git checkout, you definitely feel those extra seconds.

I feel like mucking around in the database during a conflict is a bad idea. Plus, it can get things wrong. If I merge in a migration with an older timestamp than the migration I created, rake db:migrate will put those columns at the end when my columns should be at the end (unless I rake db:schema:load first, but then a merge conflict blows away the user's database entirely). I think for anything more complex than a schema version conflict, it's probably better to just let the user handle it.