Explain why push remains on receive-pack

9529088→main·

Soph·3mo ago·1 file·+11 added/-0 removed

Sessions

df43bc263284View transcript

[?
Can you take a look at the go code (wasm) in /Users/soph/Work/entire/devenv/entire-io-worktree1 based a bit on that I wonder if something like this can be build:Codex·GPT-5.4·2 steps](/content/gh/entireio/git-sync/session/019d6d29-8cf7-7fe3-adc9-8c3e4d9d5603#timeline-df43bc263284/index.html)

Changes

1

• MREADME.md+11

113 unmodified lines

114
115
116
117
118
119
120
121
122
123
124
125
126
127

113 unmodified lines

- If `--prune` is set, managed target refs that are absent on source are deleted.
- If any ref would be blocked and `--dry-run` is not set, the command exits non-zero before pushing anything.
- `--stats` adds per-service request, byte, want, have, and command counters to the output.

## Why Push Stays V1

Protocol v2 is used where it materially improves this tool: source-side ref discovery and source-side object download.

Push remains on the existing low-level `receive-pack` path for two reasons:

- The tool already builds exact ref update commands and streams the outgoing packfile directly, so push-side control was already good before v2 support.
- The main transfer and negotiation win is on the source side. That is where `ls-refs` and `fetch` reduce unnecessary work.

In other words, this project uses protocol v2 where it changes the fetch/list behavior in a useful way, and keeps the current push path where switching protocols would mostly add complexity without a comparable payoff.

MREADME.md+11