Federated via graft
3.8 kB
38 lines
1# federation-x
2
3## What is Forge Federation?
4
5## Collaborating between tow Forgejo instances
6
7- Two Forgejo instances f1 and f2
8- **Alice** have a copy a ``federation-x`` repo on f1
9- **Bob** have a copy a ``federation-x`` repo on f2
10
11- Alice commit to federation-x and send a message to Bob asking to update his repo
12- Bob add a ``git remote`` to Alice f1 and use ``git pull f1`` to get Alice contribution
13- Alice can do the exact same thing on Bob f2
14- Now, Alice and Bob can work on the same repo but on two different forge instances
15- Question: does having a simple **sync/remote** button solve the collaboration between instances?
16
17## Solving Alice & Bob's use case with (graft)[https://f1.cyberwild.org/forgeadmin/graft]
18
191. One graft instance runs somewhere and already mirrors `federation-x` — say it started as Alice's own repo on f1, paired with a Radicle repo.
202. To bring Bob's f2 in: Bob generates a token on his own instance (scoped `write:repository` + `write:issue`), sends it to whoever runs graft — ideally through graft's own `/share/new` one-time link rather than chat. The graft admin opens `/add-peer`, picks the `federation-x` series from the dropdown, fills in f2's base URL/owner/repo and Bob's token, confirms with the admin password. The Radicle side (RID, node, explorer) is inherited from the series automatically — nobody enters it by hand.
213. Within one sync interval, no restart: f2 joins the sync loop. Bob's copy fast-forwards to whatever the federation already has.
224. From here on: Alice commits on f1 → graft relays it to Radicle → f2 picks it up on its own. Bob commits on f2 → same thing in reverse. Neither adds a git remote, neither runs `git pull`, neither messages the other.
235. If Bob doesn't want Alice's direct commits landing on f2's default branch unreviewed, the `/add-peer` form's sync-scope checkboxes let the admin leave "git" unchecked for f2 and keep only "issues" + "patches" — Alice's commits never auto-merge into f2 then; only her opened PRs do, and Bob merges them himself, on his own schedule.
24
25graft already has a switch for that — it's not "no automation at all," it's "automation for the parts you want automated, a review gate for the part you don't."
26
27
28<!--
29## Solving Alice & Bob's use case with graft
30
311. One graft instance runs somewhere and already mirrors `federation-x` — say it started as Alice's own repo on f1, paired with a Radicle repo.
322. To bring Bob's f2 in: Bob generates a token on his own instance (scoped `write:repository` + `write:issue`), sends it to whoever runs graft — ideally through graft's own `/share/new` one-time link rather than chat. The graft admin opens `/add-peer`, picks the `federation-x` series from the dropdown, fills in f2's base URL/owner/repo and Bob's token, confirms with the admin password. The Radicle side (RID, node, explorer) is inherited from the series automatically — nobody enters it by hand.
333. Within one sync interval, no restart: f2 joins the sync loop. Bob's copy fast-forwards to whatever the federation already has.
344. From here on: Alice commits on f1 → graft relays it to Radicle → f2 picks it up on its own. Bob commits on f2 → same thing in reverse. Neither adds a git remote, neither runs `git pull`, neither messages the other.
355. If Bob doesn't want Alice's direct commits landing on f2's default branch unreviewed, the `/add-peer` form's sync-scope checkboxes let the admin leave "git" unchecked for f2 and keep only "issues" + "patches" — Alice's commits never auto-merge into f2 then; only her opened PRs do, and Bob merges them himself, on his own schedule.
36
37graft already has a switch for that — it's not "no automation at all," it's "automation for the parts you want automated, a review gate for the part you don't."
38-->