Protocols

neosource separates the protocol you speak from the engine that stores your repository. What is underneath is not a Git repository on a disk somewhere — see the storage engine — and protocols are translation at the edge.

The practical consequence: you use the client you already use.

Git

Git is fully first-class and is what almost everyone should use. Both transports are implemented:

• Smart HTTP — git clone, git fetch, git push over HTTPS, using a personal access token for authentication.
• SSH — the same operations over SSH, using a key you add to your account.

This is not a Git subset or a “compatibility mode”. Ordinary git commands, ordinary remotes, ordinary workflows. See Getting started for the exact URLs and the first push.

Two edges are not implemented, both in shallow-clone territory: --shallow-since and --shallow-exclude (the deepen-since / deepen-not capabilities) are rejected rather than silently ignored, and shallow and partial clones are unavailable over the older protocol v0. Modern clients negotiate v2, where ordinary --depth works.

jj

jj works against neosource today, over the same URLs and the same transports — jj git clone, jj git fetch, jj git push.

Worth being precise about how: jj works through its Git interoperability, so there is no separate jj protocol on the wire. It drives protocol v2 through libgit2, which negotiates slightly differently from the git binary, and our edge handles that explicitly rather than accidentally.

Nothing about using neosource requires knowing what jj is, and there is no second protocol to learn or configure. If you already use jj, it works; if you do not, you lose nothing.

More over time

The engine underneath is not a Git implementation: there is no repo checked out on disk, no ref locking, and no Git object database acting as the coordination primitive. Internal dedup and membership are keyed by BLAKE3, and the manifest tier — the operation log, operation-head compare-and-swap, the pack catalog, the reachability pointer — has no Git analogue at all.

What it does store, deliberately, is Git-format packs: that format won on measurement, and it is what makes a Git clone a direct byte transfer rather than a transcode. jj already rides over those same objects as side-data — that is how a second client works today without a second store, and how additional clients over the same snapshot model would fit in future. A fundamentally different model — patch-theory versioning, or a store native to large binaries rather than Git objects — would be a sibling substrate, not a free edge onto this one.

What exists today is Git and jj; see Project status for what is designed but not yet on the wire.

Why the edge is thin

Protocol handlers translate; they do not make correctness decisions. A push arriving over SSH and a push arriving over HTTPS both end up as the same sequence in the engine: authorize, store immutable objects, append an operation record, advance the operation heads. The gateway never advances operation heads itself.

Keeping the edge thin is what makes the engine protocol-agnostic by construction: the rules about what a valid repository state is live in one place, not once per protocol.