Skip to content

Simplify deploy-tag push now that git 2.49 is the floor#6875

Draft
dannyroberts wants to merge 1 commit intomasterfrom
dmr/simplify-push-release-tag
Draft

Simplify deploy-tag push now that git 2.49 is the floor#6875
dannyroberts wants to merge 1 commit intomasterfrom
dmr/simplify-push-release-tag

Conversation

@dannyroberts
Copy link
Copy Markdown
Member

@dannyroberts dannyroberts commented May 8, 2026

https://dimagi.atlassian.net/browse/SAAS-19703

Picks up @millerdev's original suggestion on #6865. Now that #6868 / SAAS-19703 has rolled out the new git 2.49 floor across managed machines, the version-compat workaround in _push_release_tag can go away.

The previous git init --bare + git fetch --depth=1 --filter=blob:none ... <sha> + git push dance is replaced by git clone --bare --filter=blob:none --depth=1 --revision=<sha> + push. --revision was added in git 2.49.

This is a code-clarity change, not a perf one. Bytes-on-the-wire, on-disk size, and network round-trip count are unchanged (both versions already used --filter=blob:none --depth=1); wall time is within noise — see comment thread for numbers.

Environments Affected

None.

Collapses the prior init-bare + fetch + push sequence in
_push_release_tag into a single clone + push, taking advantage of
git clone --revision (added in git 2.49). PR #6868 made 2.49 the
floor on managed machines, so the version-compat workaround is no
longer needed.

Per #6865 (comment).

https://dimagi.atlassian.net/browse/SAAS-19703
@dannyroberts
Copy link
Copy Markdown
Member Author

Local performance testing from Claude Code (I didn't validate it in great detail, but the approach it took seemed generally correct.)

  ┌──────────────────────┬───────────────────────┬──────────────────────────┬─────────────┐
  │        Metric        │ Before (init + fetch) │ After (clone --revision) │      Δ      │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Wall time (avg)      │ 0.61s                 │ 0.68s                    │ +12% slower │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Bare repo size       │ 528 KB                │ 528 KB                   │ unchanged   │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Network round-trips  │ 1                     │ 1                        │ unchanged   │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Subprocesses spawned │ 2                     │ 1                        │ −1          │
  └──────────────────────┴───────────────────────┴──────────────────────────┴─────────────┘

@daniel Miller it looks like the cleaner-looking command is actually a tad slower, like ~70 ms—so basically the same speed, but not faster. (I guess git clone --bare does a bit more default setup or something than git init --bare does.) So the benefit is entirely readability / fewer lines of code as opposed to actually being more efficient. Still happy to keep this—but I wanted to check with you and see whether you still thought it was worth it.

@dannyroberts dannyroberts marked this pull request as draft May 8, 2026 17:13
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