My team has recently started using local overrides in our workflow. We also update repos with git pull --rebase by convention.
git pull --rebase
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.
bundle update foobar
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.
bundle config --delete local.foobar
bundle config local.foobar ~/path/to/foobar
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).
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.
@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: 'email@example.com:user/mygem.git', branch: 'develop'
And myproj has been configured with:
bundle config --local local.mygem ~/user/mygem
bundle update mygem
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.
bundle config --delete local.mygem
bundle config local.mygem ~/user/mygem
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.
git push ...
@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.
I'm experiencing the same issue. Removing the entry in Gemfile.lock and running bundle again works for me.
Add a spec for issue #2124 (I think)
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.
bundle "update rack"
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.
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.
Arguably a cleaner fix for issue #2124
Great, thanks for fixing this!
@JamesFerguson Awesome -- thanks so much!
@indirect: not sure how this works, but should the issue be closed if the pull request hasn't been merged?
@JamesFerguson aw, crap. Sorry, I didn't realize I hadn't merged. Doing that now...
Is this supposed to have made it into a released version yet? I'm still seeing the problem with 1.3.4.
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!