Multi-Platform Repository Management

A lot of teams have two or three forges at once. A public GitHub mirror because that is where contributors look. A private GitLab because an enterprise client insists. A Codeberg mirror because someone on the team cares about the fediverse. A Gitea instance because the infra team self-hosts on principle.

Git, stock, treats this as a pile of remotes you manage by hand. You git remote add four times, you git push four times, and on the day one of them fails half your mirrors drift. Gitorii treats mirrors as a first-class concept.

The model

A Gitorii repo has one primary mirror — the place you consider authoritative — and any number of replicas. Every torii sync pushes to all of them in one shot. If a replica fails, you get told about it; the rest still go through.

Under the hood each mirror is still a Git remote. You could read the config with plain Git and everything would make sense — we are not reinventing storage, we are reinventing the front-end.

Creating on all of them at once

The chicken-and-egg problem with mirrors is creating the remote repositories in the first place. Gitorii talks to each forge's API, so you can spin them up in one command:

That hits three APIs, creates three repos, wires them up as primary plus two replicas, and pushes your current branch. Takes about four seconds on a decent connection.

Keeping them in sync the other way

Pushing is half the story. Fetching is the other. If a teammate pushes to GitLab while you work against GitHub, stock Git silently leaves you behind until the next git fetch origin. Gitorii's autofetch polls every mirror on a schedule and warns you the moment they disagree:

When things go wrong

• Auth failure on a replica. torii sync exits non-zero and names the replica; the others still get the push.
• Replica has diverged. You get a warning and a one-command fix: torii mirror sync --force if you trust local, or torii sync <replica> to integrate from it.
• Forge is down. Autofetch marks the mirror as unreachable for the cycle and keeps going.

A note on SSH vs HTTPS

Different forges tend to prefer different auth paths. Gitorii auto-detects: if you have SSH keys configured it uses SSH, otherwise HTTPS with a stored token. You can pin either with torii config set mirror.default_protocol, or per-clone with --protocol. Run torii ssh-check once on a new machine and it will tell you exactly what is missing to connect to each configured forge.