Clarify relay-first fit in README · Entire
Clarify relay-first fit in README
91039b4→main·
Soph·3mo ago·1 file·+8 added/-0 removed
Sessions
7a24face65d3View transcript
[?
do thisCodex·GPT-5.4·1 step](/content/gh/entireio/git-sync/session/019d7d08-46c9-7f73-affe-4e6ca9852d56#timeline-7a24face65d3/index.html)
Changes
1
- MREADME.md+8
42 unmodified lines
43
44
45
46
47
48
49
50
51
52
53
54
55
56
42 unmodified lines
- you want a repeatable machine-oriented sync primitive rather than an ad hoc migration script
- you need clearer control over mapping, pruning, force rules, and relay behavior than generic shell glue usually provides
Compared to a service that keeps persistent local clones, `git-sync` is the better fit when:
- relay is common enough that streaming source-to-target is the normal case
- avoiding persistent local repo storage is an operational advantage
- remote-to-remote efficiency matters more than full local Git generality
If you need arbitrary complex reconciliation through one always-warm local full-state model, a local-clone service is still the more general tool.
The command surface is:
- `git-sync probe`: inspect a source remote, and optionally a target remote
MREADME.md+8