Skip to content

Require git >= 2.49 on managed machines#6868

Open
dannyroberts wants to merge 1 commit intomasterfrom
dmr/min-git-version
Open

Require git >= 2.49 on managed machines#6868
dannyroberts wants to merge 1 commit intomasterfrom
dmr/min-git-version

Conversation

@dannyroberts
Copy link
Copy Markdown
Member

@dannyroberts dannyroberts commented May 5, 2026

Followup to #6865 (comment). Rollout tracked in https://dimagi.atlassian.net/browse/SAAS-19703.

Environments Affected

All

  • If the changes affect multiple environments, I will ensure they are rolled out consistently across all environments.
Announce New Release
  • (Dimagi only) After merging, I will follow these instructions to announce a new commcare-cloud release.

Summary

  • Pin a minimum git version (>=1:2.49.0) on the install_git task so commcare-cloud can rely on recent git features without per-host probing.
  • Add a changelog entry directing environments to run cchq <env> deploy-stack --tags=install_git to bring all hosts up to the new minimum.

This is the prerequisite I committed to in #6865 (comment) — once this is merged, announced, and rolled out (per our usual six-week window), we can switch the deploy-tag push in #6865 to the simpler git clone --bare --filter=blob:none --depth=1 --revision={sha} ... form @millerdev originally proposed.

Why 1:2.49.0 and not 2.49.0

The 1: here is the "epoch", which in debian packaging, starts at / defaults to 0, and then can be changed to 1 (and then 2 and so on) as a hard-reset when versioning schemes change, in order to preserve ordering. For historical reasons, the ppa:git-core/ppa PPA (already configured by the role) uses epoch 1, e.g. 1:2.49.0-2~ppa1~ubuntu22.04.1. Without the explicit 1:, dpkg would compare against epoch 0, which would make >= falsely match all versions starting with epoch 1: (basically, all versions). (I think 1: is used to match the default non-ppa git, which itself uses 1: because the git name used to refer to a completely different package, GNU Interactive Tools, and they had to reset version numbers which they decided to give that name to the eventually much more popular git version control system it refers to today; but I kind of just pieced this together from scraps, so this is not the authoritative story.)

Test plan

  • Roll out on staging first: cchq staging deploy-stack --tags=install_git
  • Verify the applied diff shows only this one install command, or at least no unrelated/unnecessary commands—we don't want this accidentally rolling other stuff out
  • Confirm cchq <staging> run-shell-command all 'git --version' reports 2.49.x or later on every host

Pin a minimum git version on the install_git task so we can rely on
recent git features without per-host version checks. Includes a
changelog entry so environments can be brought up to the new minimum
before any code starts depending on it.

Discussed in #6865 (comment).
@dannyroberts dannyroberts marked this pull request as ready for review May 5, 2026 16:09
@dannyroberts dannyroberts requested a review from millerdev May 5, 2026 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant