architecture

Sync (Git + Perforce)

The version-control abstraction that lets a project speak either dialect.

Why both

Most teams that would adopt Manifoldone use Git. A specific high-value segment — game studios — runs on Perforce and is unlikely to migrate. We support both at the architecture level so the same product fits both worlds.

The abstraction

A project has a single vcs declaration:

// project.manifoldone.json
{
  "vcs": "git",   // or "perforce"
  "remote": "git@github.com:org/repo.git"
}

At the Manifoldone layer, the operations are uniform:

  • commit(intent, files) — the agent finished a change.
  • submit() — the change is ready to integrate.
  • pull() — bring local up to date.
  • branch(name) — create or switch.

Per-VCS adapters translate. Git’s commit is one thing; Perforce’s “submit a changelist” is a different thing; the surface above the adapters is the same.

Why we don’t try to invent a new VCS

We thought about it. We decided not to. Two reasons:

  1. Trust. Teams trust their VCS more than they will ever trust ours. Sitting on top is the only path to adoption.
  2. Mergeability. Git and Perforce have decades of maturity in conflict resolution. We would have to rebuild that, badly, and earn nothing in return.

The Manifoldone layer adds value by being the best automated client — generating clean commit messages, structured branches, and pre-validated change sets — not by replacing the underlying machinery.

Large binaries (the game studio reality)

Perforce is on this list partly because game projects routinely have hundreds of GB of binary assets. A Node docked to a project with large assets handles those assets locally; only metadata and intent flow through the relay. Asset uploads happen on the project’s existing Perforce infrastructure, not through Manifoldone.

v0.1 scope note

v0.1 ships Git only. Perforce support follows when there’s a design partner with an actual game project to validate against. The abstraction above is what we’re committing to long-term.