Big pushes are fast and show progress: find where a 48-commit push spent its time #202

A git push to g1t.sh hung for a long while before it finished. Find out where the time went, from Cloudflare's own records rather than guesses, and make big pushes fast and visibly progressing.

What happened (2026-10-18, around 01:00 UTC)

• git push origin work-items:main to https://g1t.sh/flagon-io/g1t.git was a fast-forward of 48 signed commits (1b57ffb2..ccd6e5e8): 574 files, +45,150 / −22,569 lines. It eventually succeeded, and CI #348, Deploy #427 and the rest started right after.
• The owner said it "hung for a while". Measure how long, and what the client showed meanwhile: did it sit silent after "Writing objects", or before it?
• Related, and already fixed: #176 (a pack that inflates past the Worker's memory is now read in place instead of answering 500).

Where to look

1. Cloudflare's records first. Use Workers Observability or Logpush for the repos Worker and whatever serves git over HTTP (find it from services/repos/src/git_http.rs and the wrangler configs). Query through the Cloudflare API or wrangler tail; deploy/stack.jsonc and scripts/deploy have the account and the names. Ask the owner for read-only Cloudflare access, use it read-only, and never print or record the credential. Pull the receive-pack request for that push: its wall time, CPU time, subrequests, D1 queries and R2/artifacts calls, and whether it hit a limit (CPU ms, subrequests, memory, request body size) and retried.
2. The push path in code. In services/repos/src: git_http.rs, store.rs, pack_cache.rs, pack_limits.rs, push_checks.rs, push_commits.rs, push_feedback.rs, pushed.rs, rules.rs, rule_facts.rs, secret_scan.rs (push protection scans the diff), signatures.rs (48 signed commits to verify), codeowners and shards.rs. Then look at what services/work does on the push event. Time each stage. The likely suspects are secret scanning a 45k-line diff, verifying 48 SSH signatures one at a time, evaluating rulesets per commit, and indexing the pack in a Worker. Measure them rather than assuming.
3. Whether the client gets progress. Over smart HTTP, sideband remote: lines let the server say what it's doing ("checking 48 commits…", "scanning for secrets…"). If the server sends nothing until the end, the client looks hung even while work is moving.

Fix

• Make the slow stages fast: batch, parallelize within Workers' limits, cache what's already checked (a commit verified once doesn't need verifying again), and move work that needn't block the push to the queue after the push is accepted.
• Send progress over sideband while the push is checked.
• Add a regression bench (see bench/ and scripts/perf): a push of that size, with timings per stage, so it can't quietly get slow again.

Verify on a scratch repository on g1t.sh, or on the local self-host stack (deploy/self-host), with a push of similar size. Report the timings per stage before and after, and what the client shows.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.