[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-1018":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":29,"discoverSource":30},1018,"git-sync","entireio\u002Fgit-sync","entireio","🪩 Mirror git refs from a source remote to a target remote without a local checkout. Packfiles stream directly over Smart HTTP and an in-memory object store.","",null,"Go",458,18,1,4,0,2,3,42,6,3.84,"MIT License",false,"main",[],"2026-06-12 02:00:22","![git-sync theme](docs\u002Fimages\u002Fgh-repo-cover.png \"git-sync cover image\")\n\n# git-sync\n\n`git-sync` mirrors refs from a source remote to a target remote without creating a local checkout. It uses an in-memory `go-git` object store and talks smart HTTP directly:\n\n- `info\u002Frefs` ref advertisement for source and target\n- `upload-pack` fetch from source with target tip hashes advertised as `have`\n- `receive-pack` push to target with explicit ref update commands and a streamed packfile\n\nThat keeps the target side incremental without fetching target objects into the local process first.\n\n## Why This Exists\n\nMirroring Git data between remotes usually means a local mirror clone followed by a mirror push. That's fine for small repos but turns a remote-to-remote operation into a local storage problem at scale, and shell glue around `git fetch` \u002F `git push` tends to skip planning and structured output.\n\n`git-sync` fills that gap. It streams source packs directly into target `receive-pack` when it can, plans every action before pushing, and emits typed JSON for automation.\n\nFor when to use it (and when not), see [docs\u002Farchitecture.md](docs\u002Farchitecture.md).\n\n## Commands\n\nThe main commands are:\n\n- `git-sync sync`: mirror source refs into the target\n- `git-sync replicate`: overwrite target refs to match source via relay, and fail rather than materialize locally\n\n`sync` automatically bootstraps an empty target, so the same command covers initial seeding and ongoing sync. To preview what would happen without pushing, run `git-sync plan` — it takes the same flags as `sync`, and `--mode replicate` previews a `replicate` run.\n\nFor command examples, JSON output, auth, protocol flags, and advanced command notes, see [docs\u002Fusage.md](docs\u002Fusage.md).\n\n## Library API\n\n`git-sync` is also a Go library. Use `entire.io\u002Fentire\u002Fgit-sync` for the stable embedding surface (`Probe`, `Plan`, `Sync`, `Replicate`, typed results, auth and HTTP injection). `entire.io\u002Fentire\u002Fgit-sync\u002Funstable` exposes advanced controls (`Bootstrap`, `Fetch`, batching knobs, heap measurement) and is not stable.\n\n## Installation\n\n### Homebrew (macOS, Linux)\n\n```bash\nbrew tap entireio\u002Ftap\nbrew install --cask git-sync\n```\n\n### `go install`\n\nRequires Go 1.26 or newer.\n\n```bash\ngo install entire.io\u002Fentire\u002Fgit-sync\u002Fcmd\u002Fgit-sync@latest\n```\n\nThis drops a `git-sync` binary into `$(go env GOPATH)\u002Fbin`. Make sure that directory is on your `PATH`.\n\n### From source\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fentireio\u002Fgit-sync.git\ncd git-sync\ngo build -o git-sync .\u002Fcmd\u002Fgit-sync\n```\n\n## Quick Start\n\n```bash\ngit-sync sync \\\n  --source-token \"$GITSYNC_SOURCE_TOKEN\" \\\n  --target-token \"$GITSYNC_TARGET_TOKEN\" \\\n  https:\u002F\u002Fgithub.com\u002Fsource-org\u002Fsource-repo.git \\\n  https:\u002F\u002Fgithub.com\u002Ftarget-org\u002Ftarget-repo.git\n```\n\nhttps:\u002F\u002Fgithub.com\u002Fuser-attachments\u002Fassets\u002F60adb873-4032-4ab7-b236-24d038e04681\n\n## Sync Behavior\n\n`sync` picks the bootstrap relay path automatically when the target is empty. For non-empty targets, safe fast-forward updates also use a relay path that streams the source pack directly into target `receive-pack` without local materialization. Anything not relay-eligible (force, prune, deletes, tag retargets) falls back to a materialized path bounded by `--materialized-max-objects`.\n\nFor branch filtering, ref mapping, tags, pruning, protocol selection, JSON output, and auth details, see [docs\u002Fusage.md](docs\u002Fusage.md).\n\n## Testing\n\nDefault suite:\n\n```bash\nenv GOCACHE=\u002Ftmp\u002Fgo-build go test .\u002F...\n```\n\nExtended and environment-specific test instructions are in [docs\u002Ftesting.md](docs\u002Ftesting.md).\n\n## Documentation\n\n- [docs\u002Fusage.md](docs\u002Fusage.md) — CLI commands, examples, sync behavior, JSON output, auth, protocol notes\n- [docs\u002Farchitecture.md](docs\u002Farchitecture.md) — product rationale, package layout, operation modes vs transfer modes, memory model\n- [docs\u002Fprotocol.md](docs\u002Fprotocol.md) — smart HTTP, pkt-line, capability negotiation, sideband, relay framing\n- [docs\u002Ftesting.md](docs\u002Ftesting.md) — test suites and integration coverage\n\n## FAQ\n\n### Does it sync complete Git history or only perform a shallow\u002Fpartial sync?\n\n`git-sync` syncs the complete Git object history required for the selected refs. It does not create a shallow clone. Some planning paths may use filtered fetches, but the target receives the full objects needed for valid refs.\n\n### Is it just refs, or objects as well?\n\nObjects as well. Refs are what `git-sync` plans and updates, but it also transfers the commits, trees, blobs, and tags needed for those refs to exist on the target.\n\n### Is it bidirectional?\n\nNo. `git-sync` is one-way: source remote to target remote. To go the other way you'd run a second invocation with the endpoints swapped.\n\n### Does it support create, update, and delete actions?\n\nYes. It supports creating refs, updating refs, force updates with `--force`, and deleting managed refs with `--prune`. `replicate` can overwrite target refs, but it is relay-only and more restrictive than `sync`.\n\n### How does it scale?\n\n`git-sync` has two transfer paths:\n\n- **Relay** — pack data streams from source `upload-pack` directly into target `receive-pack`. The local process holds no object graph, so memory stays bounded regardless of repo size. Used when the target supports relay.\n- **Materialized fallback** — when relay isn't available, `git-sync` fetches the needed objects into an in-memory `go-git` store, plans, then encodes and pushes a packfile. Memory scales with the diff being pushed and is guarded by an explicit object-count limit. Bootstrap can batch large initial syncs to keep this bounded.\n\nPlanning itself is cheap: ref-only round-trips, plus a `filter tree:0` fetch for ancestry checks when the source advertises filter support.\n\n### How long does it take for a medium-sized repo?\n\nIt depends on repository size, network speed, and whether the relay path is available. As a rule of thumb, the relay path is bounded by source pack generation + network transfer + target receive-pack time — roughly the time of a `git clone` from the source plus a `git push` of the same pack. The materialized fallback adds local memory work for objects that need inspection.\n\nFor concrete numbers on your own setup, run the included benchmark tool against a representative repo; see [docs\u002Ftesting.md](docs\u002Ftesting.md#benchmarking).\n\n### Does it support SSH?\n\nNo. `git-sync` supports smart HTTP\u002FHTTPS only.\n\n### Does it run as a daemon or watch for changes?\n\nNo. `git-sync` is a one-shot CLI\u002Flibrary operation. To sync on a schedule or in response to events, run it from cron, CI, a worker, or another service.\n\n## Contributing\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md), [SECURITY.md](SECURITY.md), and [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).\n","`git-sync` 是一个用于从源远程仓库直接同步 Git 引用到目标远程仓库的工具，无需本地检出。它利用内存中的 `go-git` 对象存储，并通过 Smart HTTP 协议直接传输数据包。该项目的核心功能包括使用 `info\u002Frefs` 广告源和目标引用、通过 `upload-pack` 从源获取数据并以 `have` 标识目标顶端哈希值、以及通过 `receive-pack` 向目标推送带有显式引用更新命令的数据包流。这些特性确保了目标端的增量更新，而无需先将目标对象下载到本地进程。`git-sync` 适用于需要在不同远程仓库之间高效同步 Git 数据的场景，尤其适合大规模或频繁更新的项目。此外，它还提供了一个 Go 库接口，支持更高级的应用集成。","2026-06-11 02:41:07","CREATED_QUERY"]