When running bundle lock --update <name>, checkout locked revision of unrelated git sources directly
#6459
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
deivid-rodriguez
changed the title
bundle lock --update <name>, don't unlock git sources unrelated to <name>bundle lock --update <name>, checkout locked revision of unrelated git sources directly
…of unrelated git sources directly Since Bundler 2.4, we will try to checkout any branch specified in the Gemfile, while until Bundler 2.3 we would directly checkout the locked revision. This should not make any difference in most situations, but in some edge cases, like if the branch specified in the `Gemfile` has been renamed, but the locked revision still exist, it causes an error now while before it would update the lockfile without issues. I debated which behavior was best, since I was not sure. But my conclusion is that if the situation does not require expiring the lockfile source in favor of the Gemfile source, we should use the locked revision directly and proceed happily. So I restored Bundler 2.3 behavior. I think this is consistent with how yanked gems are handled, for example. Of course, if explicitly updating the git source itself, or all gems, we will still get any errors like missing branches related to the git source.
deivid-rodriguez
force-pushed
the
respect-lockfile-git-sources-when-unlocking-other-gems
branch
from
7aa04da
to
c7cc74f
Compare
deivid-rodriguez
deleted the
respect-lockfile-git-sources-when-unlocking-other-gems
branch
deivid-rodriguez
added a commit
that referenced
this pull request
Mar 20, 2023
…hen-unlocking-other-gems When running `bundle lock --update <name>`, checkout locked revision of unrelated git sources directly (cherry picked from commit ac7c317)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was the end-user or developer problem that led to this PR?
Since Bundler 2.4, we will try to checkout any branch specified in the Gemfile, even if there's a locked revision in the
Gemfile.lockand the lockfile source has not been expired (for example, when runningbundle lock --update <unrelated-gem-from-a-gem-source>). Until Bundler 2.3 we would directly checkout the locked revision in this situation.This should not make any difference in most situations, but in some edge cases, like if the branch specified in the
Gemfilehas been renamed, but the locked revision still exist, it causes an error now while before it would update the lockfile without issues.What is your fix for the problem, implemented in this PR?
I debated which behavior was best, since I was not sure. But my conclusion is that if the situation does not require expiring the lockfile source in favor of the Gemfile source, we should use the locked revision directly and proceed happily. So I restored Bundler 2.3 behavior.
I think this is consistent with how yanked gems are handled, for example.
Of course, if explicitly updating the git source itself, or all gems, we will still get any errors like missing branches related to the git source.
Make sure the following tasks are checked