can you update to the latest go version?

golangci-lint is already pinned to v2.11.4 in mise.toml, which matches the latest release — no update needed.

Summary:

• go.mod and mise.toml: Go 1.25.2 → 1.26.2 (build verified)
• golangci-lint 2.11.4: already latest

Quick question before I rename — moving /pkg/gitsync → /sync changes the import path, but should the package name also change?

• Option A: Keep package name gitsync (callers still write gitsync.NewClient(...)). Less churn, but directory name doesn't match package name (un-idiomatic).
• Option B: Rename package to sync (callers write sync.NewClient(...)). Idiomatic, but shadows Go's stdlib sync — callers importing both would need an alias.
• Option C: Rename package to something else (e.g. gitsync stays as package name but directory is /sync — same as A).

Which do you want? My recommendation is A — keep the gitsync package name to avoid the stdlib clash, just move the directory.

Moving the directory, then updating all references.

All clean — build passes, tests pass, lint passes (0 issues). Final layout:

• pkg/gitsync/*.go → root (package gitsync, imported as entire.io/entire/git-sync)
• pkg/gitsync/unstable/ → unstable/
• pkg/gitsync/internalbridge/ → internalbridge/
• pkg/ directory removed
• All imports and doc references updated

Git tracked the moves as renames, so history is preserved.

Build, tests, and lint all pass with the new module path entire.io/entire/gitsync.

Note: I left cmd/git-sync (binary directory and CLI name) untouched. Let me know if you want the binary renamed to gitsync too — that would also affect the produced binary file at the repo root and any docs that reference the CLI by name.

Now I see it. The lint script filters out internal packages with this pattern:

The glob entire.io/entire/gitsync/* requires a / and at least one more character — so it matches subpackages like .../internal/auth but not the bare module path entire.io/entire/gitsync itself.

Before the refactor, the public package lived at entire.io/entire/git-sync/pkg/gitsync, so the filter caught it. Now that gitsync lives at the module root, go-licenses reports the bare module path, and the filter misses it. The repo doesn't have a top-level LICENSE file (no license keyword at the module root), so go-licenses reports Unknown.

Two ways to fix:

1. Loosen the filter to include the bare module path:

Yes, related — but the coworker is half-right. Verified the code:

Plan-time blocking — accurate. internal/syncer/syncer.go:524-526: if any plan has ActionBlock, syncer returns an error before any push happens. Nothing on the wire.

Per-ref outcome at the protocol level — accurate at the server. Receive-pack reports each ref independently via report-status, and the code does NOT request the atomic capability in buildUpdateRequest (internal/gitproto/push.go:56-98), so the server is allowed to apply some refs and reject others.

"You get per-ref outcomes in the result" — NOT accurate. This is the part to correct. Look at sendReceivePack (internal/gitproto/push.go:136-144):

The decoded report is collapsed into a single error and the per-ref data is discarded. And the Result counters (Pushed, Deleted, Skipped, Blocked) are filled in from the plan, not from the wire response (syncer.go:547-556):

This bump only runs after sendReceivePack returns nil. If it returns an error, the syncer bails with return result, err and the counters never get updated — so a partial push on the server (some refs applied, some rejected) surfaces to the caller as: error returned + zero counters + plan still in result.Plans. The caller has no per-ref breakdown of what actually landed.

So the actual atomicity story:

If you actually need atomicity at the wire layer, you'd want to set capability.Atomic in buildUpdateRequest (and the target needs to advertise it). If you want per-ref outcomes surfaced in Result, that's a code change in sendReceivePack to return the decoded ReportStatus and in the syncer to merge it into Result.Refs.

Before I write the cask file, I need to flag some blockers:

1. No GitHub release exists for entirehq/git-sync v0.1.0. Local tag exists but gh release view v0.1.0 --repo entirehq/git-sync returns "release not found". A Homebrew cask needs real download URLs + SHA256 of release assets, and there's nothing to point at yet.
2. No GoReleaser config in the gitsync repo (the existing entire.rb was generated by GoReleaser, hence the predictable URL pattern + per-platform tarballs).
3. Two directories on disk side-by-side: git-sync/ (96 bytes, empty) and gitsync/ (the real one). Just FYI — I think git-sync/ is stray.

A few possible paths — which do you want?

A. Set up the release pipeline first. Add a .goreleaser.yaml to gitsync, push tag, run release, then add a cask that mirrors entire.rb. Most work but matches the existing pattern.

B. Write the cask now with placeholder SHAs. I can write Casks/git-sync.rb modeled on entire.rb (URL pattern https://github.com/entirehq/git-sync/releases/download/v#{version}/git-sync_darwin_arm64.tar.gz etc.), with SHA256 placeholders you fill in once the release is published. Quick but requires a manual edit later.

C. Source build cask (no binaries needed). A Formula/-style Ruby that does go build from the tag tarball. Different shape from your existing tap (you only have Casks today), and slower for users to install, but works without published binaries. Probably not what you want given the existing tap pattern.

My recommendation: A, since GoReleaser is the existing pattern in your tap and you'll want this anyway. But that's a bigger lift — happy to start with B if you want something landed today and will publish binaries later.

Which way?

Writing the formula now.

Formula updated. URLs now point to github.com/entireio/gitsync (private repo confirmed), tag v0.1.0 resolves to commit b83d31d8... on the new remote. Binary name is still git-sync — built from ./cmd/git-sync and installed as bin/git-sync via std_go_args (which uses the formula filename git-sync).

Since the repo is private, install requires the user's git credentials to be configured for github.com/entireio/gitsync (SSH key or HTTPS token). Once tapped:

Want me to also add a one-line entry for git-sync in the tap's README.md?

Yes — using: :git against a public GitHub HTTPS URL needs no credentials, so it'll just work.

One small note for when you go public: the more idiomatic Homebrew pattern is to switch to a tarball URL with a sha256:

Faster install (no full git clone), and brew audit --strict prefers it over the git strategy. Functional difference is zero. I can flip the formula to that shape when you flip the repo, if you want.

Right — GitHub auto-generates archive/refs/tags/<tag>.tar.gz (and .zip) for any tag, branch, or commit in a public repo. It's not coupled to a Release object at all. A "Release" on GitHub is just metadata + optional asset attachments layered on top of a tag; the source tarball URL works as soon as the tag exists.

One small footnote: the SHA256 of GitHub's auto-generated tarballs is generally stable but not contractually guaranteed (GitHub has changed the gzip output once or twice over the years). If you ever want a checksum that's truly pinned forever, attach a self-built tarball as a release asset instead. For a small private-going-public tap, the auto-generated tarball is fine.

Done. Added a Homebrew section as the first install option, with the existing go install and source-build paths kept below as alternatives.

Want me to also update the tap's README.md (/Users/soph/Work/entire/devenv/homebrew-tap/README.md) to mention git-sync alongside the existing entire cask?

Reviewed against the code. Most of the FAQ is accurate, but Q7 (partial successes / atomic) has a factual problem that matters — it's exactly the question you just asked me about, and the answer here contradicts what's in the code.

Q7 — partial successes / atomic

"A single target receive-pack push is atomic in the normal Git sense for that push."

This is wrong, in two ways:

1. There is no "normal Git sense" of atomicity for receive-pack. Git's receive-pack is per-ref by default. The server is allowed to apply some commands and reject others. Atomicity is opt-in via the atomic capability — and buildUpdateRequest (internal/gitproto/push.go:67) only requests ReportStatus, Sideband, and DeleteRefs. It does not request capability.Atomic. Confirmed by grep: the string capability.Atomic doesn't appear anywhere in the codebase.

2. The result type silently drops the per-ref report. sendReceivePack decodes report-status but collapses it via report.Error() (push.go:141-143), discarding the per-ref outcomes. Result.Pushed/Deleted counters are then bumped from the plan (syncer.go:547-556), only on the success path. So a partial wire success surfaces to callers as: returned error + zero counters + plan still in result.Plans, with no breakdown of which refs actually landed on the server.

Suggested rewrite:

How does it deal with partial successes? Is it atomic?

Plan-time blocking is all-or-nothing: if any ref is blocked (e.g. non-fast-forward without --force), git-sync exits before pushing anything.

The wire push itself is not atomic. git-sync does not request the atomic receive-pack capability, so the target server is allowed to apply some refs and reject others. Per-ref report-status is decoded but the current Result does not surface a per-ref breakdown — partial wire failures are returned as a single error.

Across multiple push requests (notably batched bootstrap), there is also no global atomicity; batched bootstrap uses temporary refs and resume behavior to make reruns safe.

Q5 — scaling

The phrasing mixes the two paths together. Worth tightening:

"The scalable path streams pack data from the source directly into the target without materializing the full object graph locally."

True for relay, but readers don't yet know what relay vs. fallback means at this point in the doc. A small fix: name the modes explicitly ("relay path" / "materialized fallback") and note when each kicks in (relay needs target relay support; falls back to materialized when the target won't relay or when planning needs object access). One sentence each is enough.

Q6 — runtime

Currently just says "depends on size, latency, network." That's true but not useful in an FAQ. If you have any rough numbers from your own runs (e.g., "the Linux kernel via batched bootstrap takes ~X minutes on a fast link"), that's a much better answer than "it depends." If you don't want to commit to a number, I'd consider dropping the question entirely — non-answers in FAQs read as filler.

The other entries look right

• Q1 (shallow): accurate. FetchCommitGraph does use filter tree:0 (internal/gitproto/fetch.go:121) for planning, and the actual transfer is a regular fetch. Caveat captured correctly.
• Q2 (refs vs objects): correct — refs without objects can't exist on the target, this is just how Git works.
• Q3 (bidirectional): correct — one-way only, swap endpoints to mirror back.
• Q4 (CRUD): correct — ActionCreate/Update/Delete, --force, --prune all match what's in syncer.go:510-521.
• Q8 (SSH): correct — no SSH transport in the code, only smart HTTP.
• Q9 (one-shot): correct — no daemon code, no scheduler.

Want me to apply the Q7 rewrite (and tighten Q5/Q6 if you want) directly?

Good call — easier than trying to phrase the truth precisely. Let me find every "atomic" reference first.

Already gone — got it. Want me to drop Q7 from the FAQ now?

Updated. Q5 now names the two paths explicitly (relay vs materialized fallback) with the trigger condition for each, plus a one-liner on planning cost. Q6 gives a useful mental model (relay ≈ clone + push of same pack) and points to the bench tool for actual measurement.

All clean. Updated files:

• gitsync/README.md — clone URL + cd directory name
• gitsync/CONTRIBUTING.md — 5 issue/repo links
• gitsync/SECURITY.md — issue link
• homebrew-tap/Formula/git-sync.rb — homepage, url, head

Go module path entire.io/entire/gitsync left untouched as you asked.

A couple of things outside the rename you may want to handle separately:

1. Local git remote still points at git@github.com:entirehq/git-sync.git (the original org name from earlier in our session, even before the entireio/gitsync step). GitHub redirects automatically so it'll keep working, but you can update it cleanly with git remote set-url origin git@github.com:entireio/git-sync.git.
2. Local working directory is /Users/soph/Work/entire/devenv/gitsync/. Doesn't affect anything in the code, but if you want it to match the repo name, you can mv it to git-sync/ (and there's already an empty git-sync/ sibling on disk that would need to be removed first).

Good instinct — "background" is vague (conflates daemon vs. cron). A few options:

1. "Is there a daemon mode?" — direct, matches what users actually wonder
2. "Does it run as a daemon or watch for changes?" — covers both the "daemon" and "watcher/file-watch" expectation in one
3. "Does it sync continuously?" — broadest, captures both daemons and pollers

My pick is #2 — it preempts both common assumptions (long-running process AND change-watcher) in one question. Suggested phrasing:

Does it run as a daemon or watch for changes?

No. git-sync is a one-shot CLI/library operation. To sync on a schedule or in response to events, run it from cron, CI, a worker, or another service.

Want me to apply that, or pick a different one?

Applied.

Tweet checks out as marketing copy, but two small accuracy notes if you want to be precise:

1. "streaming packfiles directly" is true for the relay path, not universal. Per the README's own FAQ and Sync Behavior sections, git-sync streams source-to-target on relay-eligible operations (bootstrap + safe fast-forward updates), and falls back to a materialized path for force, prune, deletes, and tag retargets. So the tweet's framing ("streaming packfiles directly over smart HTTP") describes the headline path, not the only path. Most readers won't care, but a sharp reader who hits the materialized fallback could feel misled.

2. "streaming packfiles directly … with an in-memory object store" muddles the two paths. On pure relay, the local process holds no object graph at all (that's the whole point). The in-memory go-git store is what the fallback uses — for planning, ancestry checks, and materialized pushes. Pairing the two in one clause makes them sound like they happen together, when they're really alternatives.

Tightened version, same length:

Most git migration tools assume you'll make a local mirror clone, fetch everything down, then push it back up somewhere else. Instead, git-sync mirrors refs from a source remote to a target remote without a local checkout — streaming packfiles directly between smart-HTTP endpoints when it can, and falling back to a bounded in-memory go-git store when it has to.

Or, if you want to keep the punchier original framing and not mention the fallback at all (defensible — it's a tweet, not docs), at least drop "with an in-memory object store" since that contradicts "streaming directly":

Most git migration tools assume you'll make a local mirror clone, fetch everything down, then push it back up somewhere else. Instead, git-sync mirrors refs from a source remote to a target remote without a local checkout, streaming packfiles directly between smart-HTTP endpoints.

One more nit: "smart HTTP" is the right Git-protocol term, and you support both HTTP and HTTPS, so that part's fine.

That was me phrasing badly — there isn't a nit, I meant to confirm that part is fine. "Smart HTTP" is the correct Git-protocol term (it's the name for the protocol that runs over both http:// and https://, as opposed to the older "dumb HTTP"), and since git-sync supports HTTP/HTTPS only (no SSH), it's the right word to use. No change needed there.

Mirror Git refs between remotes without a local checkout.

50 chars. Captures the one thing that makes it different (no clone in the middle). If you want a hair more:

Mirror Git refs between remotes without a local checkout — streams packs directly over smart HTTP.