[Temikus]

What kind of change does this PR introduce?

• fix
• feat
• refactor
• perf
• docs
• test
• build / ci
• chore

Summary
Point 3 from #45, part 2: --pack-threads and --pack-window-memory, passed to upload-pack as -c pack.threads / -c pack.windowMemory. Unset = git defaults. Independent of #47.

On the GIT_CONFIG_* question: upload-pack inherits the proxy env today, so container-set GIT_CONFIG_* reaches it. Clone and fetch do not get it, because fetch_cmd sets its own GIT_CONFIG_COUNT, which replaces those entries. Nothing guarantees the inheritance, so these flags are the supported way.

Tests

• Added / updated tests (unit, plus integration where it fits)
• Not relevant, because: ...

upload_pack_runs_with_pack_options: real git serves a pack with both options set, and the recorded argv carries both -c values. git rejects a bad pack.* value, so the served pack also shows git accepted them.

Checklist

• CI is green locally: cargo fmt --all --check, cargo clippy --all-targets --all-features --locked -- -D warnings, cargo test --all-features
• Commits follow Conventional Commits; AI-assisted commits carry an Assisted-by: trailer (see CONTRIBUTING.md / AGENTS.md)
• Preserves the read-only, pull-only invariant (no push or proactive replication to upstream)
• Docs / README updated if behavior or flags changed

Breaking change?
No. New flags only; unset keeps current behavior.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.97%. Comparing base (d514d1b) to head (a57ed20).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #50      +/-   ##
==========================================
+ Coverage   96.96%   96.97%   +0.01%     
==========================================
  Files           6        6              
  Lines        2208     2218      +10     
==========================================
+ Hits         2141     2151      +10     
  Misses         67       67              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rolandjitsu]

On the GIT_CONFIG_* question:

Is this saying that the side effect of this change is that the config env vars will not be supported anymore or they weren't anyway before and providing the means to set them via the proxy is the right way?

[rolandjitsu]

On the GIT_CONFIG_* question:

Is this saying that the side effect of this change is that the config env vars will not be supported anymore or they weren't anyway before and providing the means to set them via the proxy is the right way?

We already set a few others via the proxy, so I guess the flags are the way to go.

[Temikus]

@rolandjitsu rebased, but the rustls bump is needed - sent a PR for that as well.

On the GIT_CONFIG_* question:

Is this saying that the side effect of this change is that the config env vars will not be supported anymore or they weren't anyway before and providing the means to set them via the proxy is the right way?

We already set a few others via the proxy, so I guess the flags are the way to go.

You're asking if it takes away the ability of using -c to set options, right?

In that case - no. It doesn't touch environment variables, so the container's GIT_CONFIG_* still reaches upload-pack.

I was just explaining precedence, i.e. if both set the same option, the -c value wins, because git ranks the command line above environment config.

Does this sound reasonable?

[rolandjitsu]

Does this sound reasonable?

Sounds good. Thanks.