# Clarify relay-first fit in README

`91039b4`→[main](/content/gh/entireio/git-sync/commits/main/index.html)·
  
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