Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Force update a gem with a local override when locked revision isn't in the current branch #2124

Closed
JamesFerguson opened this Issue · 18 comments

6 participants

@JamesFerguson

My team has recently started using local overrides in our workflow. We also update repos with git pull --rebase by convention.

I am now routinely running into the error "The Gemfile lock is pointing to revision ac2cad5 but the current branch in your local override for foobar does not contain such commit. Please make sure your branch is up to date."

The problem arises because if I make a local commit to foobar then the project that depends on foobar gets locked to the sha of that commit, but when I git pull --rebase in order to push that commit out the rebase results in my local commit having a new sha. The old sha points to an unreferenced commit that is no longer on any branch which triggers the error.

When I try to bundle I get the aforementioned error, which is fine because the Gemfile.lock is now invalid.

More problematic however is that when I bundle update foobar I still get the same error. Given I've explicitly asked bundler to replace the sha in Gemfile.lock with the latest available sha by calling bundle update foobar complaining that the old sha is no longer in the specified branch seems beside the point.

At present I have to bundle config --delete local.foobar, then bundle and then bundle config local.foobar ~/path/to/foobar again to workaround this.

At the least it seems reasonable to ask for a --force option for bundle update foobar to ignore the error and just overwrite the old sha. But it seems like a bug to me, and that the default behaviour should just be to overwrite the old sha.

As a side note, given how frequently this error is likely to come up if you use local override and a rebase workflow, it would be good if the above error message included the suggestion that you bundle update foobar to resolve the issue (if indeed a change is made so that doing that would resolve the issue).

Thanks,

James

@indirect
Owner

Hmmmm that definitely sounds like a bug in the locals code. It should update to the current sha when you run bundle update foobar. If you have time to write a pull for this, that would be awesome. If not, I expect I'll look at this in roughly a week.

@alirz23

It does indeed update the sha when you run bundle update foobar. I could not reproduce the error.

@indirect
Owner

@alirz23 thanks for looking into this!

@JamesFerguson, can you provide more detailed reproduction steps?

@JamesFerguson

Ok, so there are two repos, lets call them myproj and mygem.

And myproj has a line in its Gemfile:

gem 'mygem', git: 'git@github.com:user/mygem.git', branch: 'develop'

And myproj has been configured with:

bundle config --local local.mygem ~/user/mygem

To reproduce:

  1. Make a commit to mygem
  2. bundle myproj
  3. Ensure there are new commits to pull from mygem's origin.
  4. Do a git pull --rebase on mygem
  5. Now try to bundle on myproj and you will (correctly) get the error mentioned.
  6. Now try to bundle update mygem on myproj and you will (I think incorrectly) still see the error.

Thanks for looking at this.

@JamesFerguson

As I say above, once you're in that state the only way out is to bundle config --delete local.mygem then bundle update mygem then bundle config local.mygem ~/user/mygem again.

I've realised while trying to reproduce this that if you always git pull --rebase and then git push ... on mygem between the time that you make commits to mygem and anytime you bundle myproj, then you won't have this problem. That is, if you never bundle against a repo path that is ahead of its origin then you won't get this issue.

@alirz23

@JamesFerguson thanks for your reply I will have look at it

@emcmanus

Can replicate this issue any time the referenced SHA disappears.

All history changing operations, rebase included, potentially leave you in this state.

@gerhard

I'm experiencing the same issue. Removing the entry in Gemfile.lock and running bundle again works for me.

@JamesFerguson JamesFerguson referenced this issue from a commit in JamesFerguson/bundler
JamesFerguson Add a spec for issue #2124 (I think) 7fa33cc
@JamesFerguson

I created a spec that I think covers this issue. It's based on the only spec that deals with the "The Gemfile lock is pointing to revision" which is in spec/install/git_spec.rb and I've added it to spec/update/git_spec.rb.

Interestingly it didn't fail for bundle :update, only for bundle "update rack". So it seems the error is bypassed when doing a full update on all dependencies, just not if you try to update the specific gem that has had history rewritten.

I should warn you that I've only spent an hour on this so I can't promise that the spec is testing what I think it's testing.

@JamesFerguson JamesFerguson referenced this issue from a commit in JamesFerguson/bundler
JamesFerguson Fix for issue #2124
 - don't complain if local_override being updated anyway
e090536
@JamesFerguson

The fix above makes my spec pass and doesn't break any others. I haven't yet managed to test it manually on an actual project.

@JamesFerguson JamesFerguson referenced this issue from a commit in JamesFerguson/bundler
JamesFerguson Arguably a cleaner fix for issue #2124 149f419
@indirect
Owner

Great, thanks for fixing this!

@indirect indirect closed this
@emcmanus

@JamesFerguson Awesome -- thanks so much! :smiley:

@JamesFerguson

@indirect: not sure how this works, but should the issue be closed if the pull request hasn't been merged?

@indirect
Owner

@JamesFerguson aw, crap. Sorry, I didn't realize I hadn't merged. Doing that now...

@aspiers

Is this supposed to have made it into a released version yet? I'm still seeing the problem with 1.3.4.

@aspiers

Ah, I see 1.3.4 was released 3 days before the fix got merged. Any chance of a 1.3.5 with the fix? Thanks!

@indirect
Owner
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.