You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I personally use a different resolution strategy for both migrations and bundler.
Bundler
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.
If there is a conflict in Gemfile.lock, I propose the following resolution strategy:
git checkout Gemfile.lock -- <older branch>
bundle install
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
git checkout db/schema.rb -- <older branch>
rake db:migrate
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?
The text was updated successfully, but these errors were encountered:
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.
I personally use a different resolution strategy for both migrations and bundler.
Bundler
bundle install
without running the check first. If the check is required, that's a bug. So if theGemfile
changes, it should be equally fast to runbundle install
again.Gemfile.lock
, I propose the following resolution strategy:git checkout Gemfile.lock -- <older branch>
bundle install
Gemfile
andGemfile.lock
, and will properly handle all the edge-cases we know aboutMigrations
For similar reasons, I propose the following resolution strategy for conflicts in schema.rb
git checkout db/schema.rb -- <older branch>
rake db:migrate
rake db:migrate
knows how to bring aschema.rb
up to date with newer migrationsIs there any reason my thinking here is incorrect?
The text was updated successfully, but these errors were encountered: