Skip to content

Commit

Permalink
When running bundle lock --update <name>, checkout locked revision …
Browse files Browse the repository at this point in the history
…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.
  • Loading branch information
deivid-rodriguez authored and hsbt committed Mar 17, 2023
1 parent 0b9e51c commit c65d7b4
Show file tree
Hide file tree
Showing 2 changed files with 43 additions and 0 deletions.
5 changes: 5 additions & 0 deletions lib/bundler/source/git/git_proxy.rb
Expand Up @@ -366,6 +366,11 @@ def extra_clone_args
args += ["--single-branch"]
args.unshift("--no-tags") if supports_cloning_with_no_tags?

# If there's a locked revision, no need to clone any specific branch
# or tag, since we will end up checking out that locked revision
# anyways.
return args if @revision

args += ["--branch", branch || tag] if branch || tag
args
end
Expand Down
38 changes: 38 additions & 0 deletions spec/bundler/commands/lock_spec.rb
Expand Up @@ -158,6 +158,44 @@ def read_lockfile(file = "Gemfile.lock")
expect(out).not_to include("re-resolving dependencies because the list of sources changed")
end

it "updates specific gems using --update using the locked revision of unrelated git gems for resolving" do
ref = build_git("foo").ref_for("HEAD")

gemfile <<-G
source "#{file_uri_for(gem_repo1)}"
gem "rake"
gem "foo", :git => "#{file_uri_for(lib_path("foo-1.0"))}", :branch => "deadbeef"
G

lockfile <<~L
GIT
remote: #{file_uri_for(lib_path("foo-1.0"))}
revision: #{ref}
branch: deadbeef
specs:
foo (1.0)
GEM
remote: #{file_uri_for(gem_repo1)}/
specs:
rake (10.0.1)
PLATFORMS
#{lockfile_platforms}
DEPENDENCIES
foo!
rake
BUNDLED WITH
#{Bundler::VERSION}
L

bundle "lock --update rake --verbose"
expect(out).to match(/Writing lockfile to.+lock/)
expect(lockfile).to include("rake (13.0.1)")
end

it "errors when updating a missing specific gems using --update" do
lockfile @lockfile

Expand Down

0 comments on commit c65d7b4

Please sign in to comment.