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

JamesFerguson opened this Issue Oct 17, 2012 · 18 comments


None yet
6 participants

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).




indirect commented Oct 17, 2012

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.

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


indirect commented Oct 24, 2012

@alirz23 thanks for looking into this!

@JamesFerguson, can you provide more detailed reproduction steps?

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

And myproj has a line in its Gemfile:

gem '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.

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.

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

Can replicate this issue any time the referenced SHA disappears.

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

gerhard commented Mar 4, 2013

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

JamesFerguson pushed a commit to JamesFerguson/bundler that referenced this issue Mar 5, 2013

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 pushed a commit to JamesFerguson/bundler that referenced this issue Mar 5, 2013

JamesFerguson JamesFerguson
Fix for issue #2124
 - don't complain if local_override being updated anyway

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 pushed a commit to JamesFerguson/bundler that referenced this issue Mar 5, 2013


indirect commented Mar 6, 2013

Great, thanks for fixing this!

@indirect indirect closed this Mar 6, 2013

emcmanus commented Mar 6, 2013

@JamesFerguson Awesome -- thanks so much! 😃

np :)

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


indirect commented Mar 18, 2013

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

indirect added a commit that referenced this issue Mar 18, 2013

Merge pull request #2362 from JamesFerguson/1-3-stable
Fixes #2124: ignore bad local override revisions if updating the dependency anyway


aspiers commented Mar 23, 2013

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

aspiers commented Mar 23, 2013

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 commented Mar 24, 2013

1.3.5 will be out soon �\ I was mostly trying to make sure I didn't miss any other new bugs in 1.3.4 :)

On Mar 23, 2013, at 5:57 AM, Adam Spiers wrote:

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!

Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment