feat(git): install git from the containerbase prebuild

[viceice]

Changes

install-tool git installs git from the containerbase/git-prebuild releases instead of the git-core PPA:

• the shared prebuild helper downloads the jammy build (also used on noble and resolute) and verifies the .sha512
• git is linked as plain symlinks (git, git-receive-pack, git-shell, git-upload-archive, git-upload-pack, scalar) instead of the shell wrapper, so signals (e.g. Renovate's git timeout) reach git and its environment isn't changed
• exact versions from 2.48.0 install without a lookup; partial versions, versions before 2.48.0 and other version strings fall back to the newest prebuild with a warning, so pins that worked with the PPA (which ignored the version) keep working
• runtime libraries are installed on prepare and on install (images prepared with the old PPA keep its apt source)
• for compatibility until the next major: Ubuntu git's former dependencies (perl, liberror-perl, git-man, gnutls libcurl) are still installed (Stop installing git's former Ubuntu dependencies #7821), and the binaries are also linked in /usr/bin (Remove the git compatibility links in /usr/bin #7822)
• needsRoot, /etc/gitconfig and safe.directory '*' stay; container tests check the links, version, system config origin, https clone and git-lfs
• docs list the release URLs for mirrors

Context

Please select one of the following:

• This closes an existing Issue, Closes: Install git from the git-prebuild releases #7778
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Code, tests and docs written with Claude Code (Claude Opus 5.5).

Use of AI in replying to PR comments

Who answers review comments:

• @viceice will read and reply directly. Name the account.
• An agent will draft replies and @username will read them before they are posted. Name the account.
• An agent will draft replies and reply autonomously. This is heavily discouraged, and we prefer that there are humans in the loop
• Nobody has explicitly committed to replying.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified tests

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 3 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: containerbase/coderabbit/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 4f149cb6-da3b-4521-8448-ce35a6e7eaf0

📥 Commits

Reviewing files that changed from the base of the PR and between 5fc0406 and 725fe85.

📒 Files selected for processing: 18

• Dockerfile
• docs/custom-base-image.md
• docs/custom-registries.md
• src/cli/install-tool/base-install.service.ts
• src/cli/install-tool/version-resolvers.ts
• src/cli/tools/git/index.spec.ts
• src/cli/tools/git/index.ts
• test/Dockerfile.distro
• test/flutter/Dockerfile
• test/flutter/Dockerfile.arm64
• test/golang/Dockerfile
• test/golang/Dockerfile.arm64
• test/java/Dockerfile
• test/latest/Dockerfile
• test/latest/Dockerfile.arm64
• test/ruby/Dockerfile
• test/ruby/Dockerfile.arm64
• test/swift/Dockerfile

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: containerbase/coderabbit/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: ecbf0ed6-f295-45ea-9ddf-23eb1f656e1c

📥 Commits

Reviewing files that changed from the base of the PR and between 5f1e35f and 5fc0406.

📒 Files selected for processing: 22

• Dockerfile
• docs/custom-base-image.md
• docs/custom-registries.md
• packages/base/data/tools.json
• packages/base/src/data.ts
• src/cli/install-tool/base-install.service.ts
• src/cli/install-tool/index.spec.ts
• src/cli/install-tool/version-resolvers.ts
• src/cli/tools/git/index.spec.ts
• src/cli/tools/git/index.ts
• test/Dockerfile.distro
• test/flutter/Dockerfile
• test/flutter/Dockerfile.arm64
• test/golang/Dockerfile
• test/golang/Dockerfile.arm64
• test/java/Dockerfile
• test/latest/Dockerfile
• test/latest/Dockerfile.arm64
• test/packages/base.spec.ts
• test/ruby/Dockerfile
• test/ruby/Dockerfile.arm64
• test/swift/Dockerfile

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Walkthrough

Git installation now uses containerbase/git-prebuild releases instead of the Git PPA. The minimum supported version is 2.48.0. Version resolution, base-image examples, registry documentation, and container checks are updated to use the prebuild releases.

Changes: Git prebuild installation

Layer / File(s)	Summary
Install Git from prebuilt releases packages/base/data/tools.json, packages/base/src/data.ts, src/cli/install-tool/base-install.service.ts, src/cli/tools/git/index.ts, src/cli/tools/git/index.spec.ts, src/cli/install-tool/index.spec.ts, test/packages/base.spec.ts	Git preparation now installs distro-specific runtime packages instead of configuring the PPA. GitInstallService uses the prebuild installation flow, validates versions against 2.48.0, and retains system safe-directory configuration. Tool metadata and installation tests reflect the minimum version and changed flow.
Resolve Git versions src/cli/tools/git/index.ts, src/cli/install-tool/version-resolvers.ts, src/cli/tools/git/index.spec.ts	The built-in resolver registry includes GitVersionResolver. Full semantic versions below 2.48.0 resolve to the latest prebuild with a warning. Other inputs follow the prebuild resolver behavior. Tests cover these cases.
Use and verify Git prebuild releases Dockerfile, docs/custom-base-image.md, docs/custom-registries.md, test/{flutter,golang,java,ruby,swift}/*, test/Dockerfile.distro, test/latest/Dockerfile*	Base-image examples and test images use containerbase/git-prebuild releases. Registry documentation describes release archives, checksums, the latest-version lookup, and fallback behavior. Container checks cover Git and Git LFS versions, configuration, and repository operations.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant InstallTool as install-tool
  participant GitVersionResolver
  participant PrebuildVersionResolver
  InstallTool->>GitVersionResolver: resolve(requested version)
  alt Full semantic version below 2.48.0
    GitVersionResolver->>PrebuildVersionResolver: resolve(latest)
  else Other input
    GitVersionResolver->>PrebuildVersionResolver: resolve(input)
  end
  PrebuildVersionResolver-->>GitVersionResolver: resolved version
  GitVersionResolver-->>InstallTool: resolved version

Loading

Merge Risk: ⚪ Minimal · up to 5fc04

No actionable issue was established in the Git prebuild change. It is mergeable after normal checks.

Pre-merge checks: 5

Check name	Status	Explanation
Linked Issues check		Issue #7778 is directly linked and has coding requirements. GitPrepareService removes PPA setup and installs runtime packages. GitInstallService uses PrebuildInstallService, retains needsRoot,…
Out of Scope Changes check		The changed Dockerfiles and custom base-image documentation update Git installation references to the new containerbase/git-prebuild source. The added unit and container tests verify the linked Git …
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 7…
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: installing Git from the containerbase prebuild.

Full details: Linked Issues check

Explanation

Issue #7778 is directly linked and has coding requirements. GitPrepareService removes PPA setup and installs runtime packages. GitInstallService uses PrebuildInstallService, retains needsRoot, canUninstall = false, global linking, /etc/gitconfig, and safe.directory '*'. GitVersionResolver handles the 2.48.0 minimum and fallback warning. Tests cover Jammy runtime packages, x64 and arm64 archives, checksum retrieval, linking, metadata, HTTPS cloning, and Git LFS. docs/custom-registries.md documents release, checksum, latest-version, and mirror URLs.

Full details: Out of Scope Changes check

Explanation

The changed Dockerfiles and custom base-image documentation update Git installation references to the new containerbase/git-prebuild source. The added unit and container tests verify the linked Git migration. Resolver registration, metadata updates, and service documentation support the same objective. No unrelated change is demonstrated.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 7 files. (15 skipped: 15 unsupported.)

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Install Git from containerbase prebuild releases

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 40+ Minutes

AI Description

• Replace the git-core PPA with checksum-verified, versioned Git prebuilds.
• Preserve existing version pins and Ubuntu package compatibility while linking Git without
 signal-blocking wrappers.
• Document mirror requirements and test Git, HTTPS cloning, and Git LFS across container images.

Diagram

graph TD
  R["Git resolver"] --> I["Git installer"] --> P["Prebuild release"] --> T["Versioned Git"] --> L["Git symlinks"] --> C["Git callers"]
  I --> A["Apt libraries"]
  Q["Git prepare"] --> A

Loading

High-Level Assessment

Reusing the shared prebuild installer and resolver is the best fit for versioned, checksum-verified Git. Retaining the PPA would still ignore requested versions, while the shared installer's default shell wrapper would interfere with Git signals and its caller's environment; the Git-specific direct links address that difference.

Files changed (18) +520 / -175

Enhancement (2) +122 / -73

version-resolvers.tsRegister the Git prebuild version resolver +2/-0

Register the Git prebuild version resolver

• Adds Git's resolver to the install-tool resolver registry so requested versions are resolved before installation.

src/cli/install-tool/version-resolvers.ts

index.tsReplace PPA Git installation with verified prebuilds +120/-73

Replace PPA Git installation with verified prebuilds

• Installs distro-specific runtime and compatibility packages, inherits checksum-verified prebuild installation, and links Git binaries without wrappers. Adds exact-version and fallback resolution while retaining root-only installation, system safe-directory configuration, and the uninstall restriction.

src/cli/tools/git/index.ts

Tests (12) +359 / -88

index.spec.tsTest Git prebuild installation and compatibility +228/-66

Test Git prebuild installation and compatibility

• Replaces PPA assertions with coverage for distro packages, architecture-specific downloads, version fallback, direct links, and retained system configuration.

src/cli/tools/git/index.spec.ts

Dockerfile.distroExercise Git prebuilds in distro images +61/-2

Exercise Git prebuilds in distro images

• Checks executable links, Git behavior, HTTPS access, the oldest prebuild, version fallback, and Git LFS integration in container builds.

test/Dockerfile.distro

DockerfilePin Flutter test Git to a prebuild release +2/-2

Pin Flutter test Git to a prebuild release

• Changes the Git install command and Renovate source to the containerbase prebuild release.

test/flutter/Dockerfile

Dockerfile.arm64Pin ARM64 Flutter test Git to a prebuild release +2/-2

Pin ARM64 Flutter test Git to a prebuild release

• Changes the ARM64 Flutter image's Git install command and Renovate source to the prebuild release.

test/flutter/Dockerfile.arm64

DockerfilePin Go test Git to a prebuild release +2/-2

Pin Go test Git to a prebuild release

• Switches the Go test image's Git pin and Renovate source to containerbase/git-prebuild.

test/golang/Dockerfile

Dockerfile.arm64Pin ARM64 Go test Git to a prebuild release +2/-2

Pin ARM64 Go test Git to a prebuild release

• Switches the ARM64 Go test image's Git pin and Renovate source to containerbase/git-prebuild.

test/golang/Dockerfile.arm64

DockerfilePin Java test Git to a prebuild release +2/-2

Pin Java test Git to a prebuild release

• Changes the Java test image's Git pin and Renovate source to the prebuild release.

test/java/Dockerfile

DockerfileTest prebuilt Git with Git LFS on the latest image +27/-2

Test prebuilt Git with Git LFS on the latest image

• Updates the Git pin and adds non-root checks for Git links, execution, system configuration, HTTPS cloning, and Git LFS.

test/latest/Dockerfile

Dockerfile.arm64Test ARM64 prebuilt Git and Git LFS +27/-2

Test ARM64 prebuilt Git and Git LFS

• Updates the Git pin and verifies non-root Git execution, configuration, HTTPS cloning, and Git LFS integration on ARM64.

test/latest/Dockerfile.arm64

DockerfilePin Ruby test Git to a prebuild release +2/-2

Pin Ruby test Git to a prebuild release

• Switches the Ruby test image's Git pin and Renovate source to containerbase/git-prebuild.

test/ruby/Dockerfile

Dockerfile.arm64Pin ARM64 CocoaPods test Git to a prebuild release +2/-2

Pin ARM64 CocoaPods test Git to a prebuild release

• Switches the Git installation used by the ARM64 CocoaPods test stage to the prebuild release.

test/ruby/Dockerfile.arm64

DockerfilePin Swift test Git to a prebuild release +2/-2

Pin Swift test Git to a prebuild release

• Changes the Swift test image's Git pin and Renovate source to containerbase/git-prebuild.

test/swift/Dockerfile

Documentation (3) +37 / -12

custom-base-image.mdDocument prebuilt Git in custom images +16/-6

Document prebuilt Git in custom images

• Updates example Git pins and explains the temporary Ubuntu package and /usr/bin link compatibility provisions.

docs/custom-base-image.md

custom-registries.mdDocument Git release and mirror requirements +19/-3

Document Git release and mirror requirements

• Replaces PPA guidance with prebuild URLs, checksum requirements, version fallback behavior, and runtime dependency guidance.

docs/custom-registries.md

base-install.service.tsCorrect base installer documentation for Git +2/-3

Correct base installer documentation for Git

• Updates comments to reflect Git's continued root and uninstall restrictions without describing it as an apt-installed tool.

src/cli/install-tool/base-install.service.ts

Other (1) +2 / -2

DockerfileBuild the base image with prebuilt Git +2/-2

Build the base image with prebuilt Git

• Switches the Git pin and Renovate source from upstream Git tags to containerbase/git-prebuild releases.

Dockerfile

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (2)

1. Java arm64 image skips Git coverage 📘 Rule violation ⭐ New

Description

The Java amd64 fixture now installs Git at test/java/Dockerfile:24, but its matching arm64 fixture
has no corresponding install-tool git step. Arm64 Java images therefore do not exercise the
changed Git installer, leaving that supported architecture untested.

Code

test/java/Dockerfile[R23-24]

+# renovate: datasource=github-releases packageName=containerbase/git-prebuild
+RUN install-tool git 2.56.0

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Java test suite now exercises the Git installer only on amd64, while the matching arm64 Dockerfile has no Git installation test.

## Fix Focus Areas
- test/java/Dockerfile.arm64[20-24]
- test/java/Dockerfile[23-24]

## Recommended Fix
Add the same Renovate annotation and literal `RUN install-tool git 2.56.0` command to `test/java/Dockerfile.arm64`, keeping the amd64 and arm64 fixtures consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

2. Swift arm64 image skips Git coverage 📘 Rule violation ⭐ New

Description

The Swift amd64 fixture now installs Git at test/swift/Dockerfile:24, but its matching arm64
fixture has no corresponding install-tool git step. Arm64 Swift images therefore do not exercise
the changed Git installer, leaving that supported architecture untested.

Code

test/swift/Dockerfile[R23-24]

+# renovate: datasource=github-releases packageName=containerbase/git-prebuild
+RUN install-tool git 2.56.0

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Swift test suite now exercises the Git installer only on amd64, while the matching arm64 Dockerfile has no Git installation test.

## Fix Focus Areas
- test/swift/Dockerfile.arm64[20-24]
- test/swift/Dockerfile[23-24]

## Recommended Fix
Add the same Renovate annotation and literal `RUN install-tool git 2.56.0` command to `test/swift/Dockerfile.arm64`, keeping the amd64 and arm64 fixtures consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

3. Git fallback test passes even when the install fails 🐞 Bug ⭐ New

Description

The test-git-min stage runs install-tool git 2.40.0 2>&1 | tee /git-fallback.log under set -ex
with no pipefail, so the step's exit status is tee's, not install-tool's. The resolver logs
its fallback warning before it downloads anything, so the next grep still passes and `git
--version still succeeds with the 2.56.0 already installed in base`, which means a broken fallback
install never fails CI.

Code

test/Dockerfile.distro[R56-60]

+RUN set -ex; \
+  install-tool git 2.40.0 2>&1 | tee /git-fallback.log; \
+  grep -F 'No git 2.40.0 prebuild, installing the newest git ' /git-fallback.log; \
+  [ ! -e /opt/containerbase/tools/git/2.40.0 ]; \
+  git --version; \

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `test/Dockerfile.distro`, the `test-git-min` stage pipes `install-tool git 2.40.0` into `tee` without `pipefail`. If the install fails, the step's exit status still comes from `tee`. The warning grep and `git --version` (git 2.56.0 from `base`) both still pass, so the test cannot catch a broken fallback install.

## Fix Focus Areas
- test/Dockerfile.distro[56-62]

## Recommended Fix
Redirect the output to the file instead of piping it, so the step fails when `install-tool` fails: `install-tool git 2.40.0 > /git-fallback.log 2>&1 || { cat /git-fallback.log; exit 1; }; cat /git-fallback.log;`. Alternatively, add `SHELL ["/bin/bash", "-o", "pipefail", "-c"]` before the step. Then check that the version actually installed is the newest prebuild, e.g. compare `git --version` with the version in the log line, so the check proves the fallback install happened.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

View medium (1)

4. New git test stage never exercises a real install 🐞 Bug

Description

The test-git stage added in test/latest/Dockerfile is built FROM base, and base already ran
RUN install-tool git 2.56.0 earlier in the same file, so versionSvc.isInstalled returns true and
install-tool.service.ts takes the already-installed short-circuit, skipping install() entirely
and only re-linking and re-testing. The assertions in this stage (version string, safe.directory,
git-lfs, clone) therefore never validate the prebuild download, checksum verification or extraction
path that this PR introduces, which is the part of the change most in need of container-level
coverage.

Code

test/latest/Dockerfile[R402-408]

+FROM base AS test-git
+
+# renovate: datasource=github-releases packageName=containerbase/git-prebuild
+RUN install-tool git 2.56.0
+
+# renovate: datasource=github-releases packageName=git-lfs/git-lfs
+RUN install-tool git-lfs v3.8.0

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `test-git` stage in `test/latest/Dockerfile` is built `FROM base`, which already ran `install-tool git 2.56.0` earlier in the file. Because the version matches, `InstallToolService.install` takes the "already installed" short-circuit and never calls `install()`, so this new test never exercises the prebuild download/checksum/extract path introduced by this PR.

## Fix Focus Areas
- test/latest/Dockerfile[402-422]
- test/latest/Dockerfile[173-181]

## Recommended Fix
Either build the `test-git` stage from a base image that has not already installed git (so the `RUN install-tool git 2.56.0` triggers a real download), or pin a different git version in this stage than the one installed in the `base` stage so the install path actually runs, then keep the existing version/lfs/clone assertions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

View low (1)

5. Pinned git versions with a leading v install latest 🐞 Bug

Description

GitVersionResolver.resolve puts the requested version into the prebuild URL exactly as given, so
v2.56.0 (the old documented and Renovate-managed form install-tool git v2.56.0 with
datasource=github-tags packageName=git/git) never matches a release tag and falls back to
super.resolve('latest'). Images that pin git this way quietly get whatever prebuild is newest when
they build, with only a warning, so builds are no longer reproducible even though a matching
2.56.0 prebuild exists.

Code

src/cli/tools/git/index.ts[R97-100]

+    const url = await prebuildUrl(this.tool, version, this.env.arch);
+    if (await this.http.exists(`${url}.sha512`)) {
+      return version;
    }
-    return coerced.version;

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`GitVersionResolver.resolve` uses the requested version as given. A legacy pin like `v2.56.0`, which the old docs and the `git/git` github-tags Renovate config used, always gets a 404 and falls back to the newest prebuild, so the pin is lost.

## Fix Focus Areas
- src/cli/tools/git/index.ts[90-107]

## Recommended Fix
Before building the prebuild URL, normalise the version with `version = version.replace(/^v/, '')`. Then check the `.sha512` for the normalised version and return that, so `v2.56.0` installs 2.56.0. Add a unit test for the `v`-prefixed case.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

Resolved findings

1. Installed Git cannot be reselected offline ✓ Resolved

Description

GitVersionResolver.resolve() sends a checksum HEAD request for every explicit version, even when
that version is already installed locally. The command resolves the version before checking
installed state, so rerunning install-tool git 2.56.0 fails during a network outage instead of
taking the existing-install path.

Code

src/cli/tools/git/index.ts[R97-99]

+    const url = await prebuildUrl(this.tool, version, this.env.arch);
+    if (await this.http.exists(`${url}.sha512`)) {
+      return version;

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Reselecting an already installed Git version requires a successful network request because the resolver probes the release before the installer checks local state.
## Fix Focus Areas
- src/cli/tools/git/index.ts[90-106]
- src/cli/command/install-tool.ts[74-92]
- src/cli/install-tool/install-tool.service.ts[84-103]
## Recommended Fix
Check whether an explicit Git version is already installed before probing the release, and return that version directly when it is. Retain the remote existence check and fallback for versions that are not installed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Partial version pins now fail instead of falling back ✓ Resolved

Description

GitVersionResolver.resolve only applies the pre-2.48.0 fallback when the version matches the
strict ^\d+\.\d+\.\d+$ shape; a partial pin like 2.30 or 2 falls through to
super.resolve(version), which returns it unchanged, and the subsequent
GitInstallService.validate then rejects it via semverGte. The PR description states old pins
that worked with the git-core PPA (which ignored the requested version entirely) keep working, but a
non-full-triplet old pin now hard-fails the install instead of being silently upgraded like a full
X.Y.Z pre-2.48.0 version is.

Code

src/cli/tools/git/index.ts[R90-98]

+  override async resolve(
+    version: string | undefined,
+  ): Promise<string | undefined> {
+    if (
+      !version ||
+      !/^\d+\.\d+\.\d+$/.test(version) ||
+      semverGte(version, minVersion)
+    ) {
+      return await super.resolve(version);

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`GitVersionResolver.resolve` only triggers the pre-2.48.0 fallback for versions matching the strict `X.Y.Z` pattern. A partial pin such as `2.30` or `2` skips the fallback and is passed through unchanged, then fails `GitInstallService.validate`, which is inconsistent with the PR's stated goal that old pins keep working.

## Fix Focus Areas
- src/cli/tools/git/index.ts[90-105]

## Recommended Fix
Either normalize/coerce the incoming version (e.g. with the existing semver coerce utility) before testing it against `minVersion`, or explicitly document that only full `X.Y.Z` pins get the automatic fallback and partial pins must be updated by the user.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can pick a display mode instead of tweaking every Display option by hand

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[viceice]

/review

[qodo-code-review]

1. Java arm64 image skips git coverage 📘 Rule violation ▣ Testability

The Java amd64 fixture now installs Git at test/java/Dockerfile:24, but its matching arm64 fixture
has no corresponding install-tool git step. Arm64 Java images therefore do not exercise the
changed Git installer, leaving that supported architecture untested.

Agent Prompt

## Issue description
The Java test suite now exercises the Git installer only on amd64, while the matching arm64 Dockerfile has no Git installation test.

## Fix Focus Areas
- test/java/Dockerfile.arm64[20-24]
- test/java/Dockerfile[23-24]

## Recommended Fix
Add the same Renovate annotation and literal `RUN install-tool git 2.56.0` command to `test/java/Dockerfile.arm64`, keeping the amd64 and arm64 fixtures consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

[qodo-code-review]

2. Swift arm64 image skips git coverage 📘 Rule violation ▣ Testability

The Swift amd64 fixture now installs Git at test/swift/Dockerfile:24, but its matching arm64
fixture has no corresponding install-tool git step. Arm64 Swift images therefore do not exercise
the changed Git installer, leaving that supported architecture untested.

Agent Prompt

## Issue description
The Swift test suite now exercises the Git installer only on amd64, while the matching arm64 Dockerfile has no Git installation test.

## Fix Focus Areas
- test/swift/Dockerfile.arm64[20-24]
- test/swift/Dockerfile[23-24]

## Recommended Fix
Add the same Renovate annotation and literal `RUN install-tool git 2.56.0` command to `test/swift/Dockerfile.arm64`, keeping the amd64 and arm64 fixtures consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗