mitosis fork workflow #70
Labels
No labels
bug
discussion
duplicate
enhancement
goal
help wanted
horizon:backlog
horizon:governance
horizon:mvp
invalid
operator-decision
question
roadmap
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
open-platform/mitosis#70
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
mitosis deployments should fork their parent mitosis instead of deploying their own from scratch. this will track genealogy while also allowing platform maintainers to develop their own version of mitosis which can deploy downstream of them. in the case of null like the origin got removed or something, default to git.open-platform.sh/plat/mitosis. this should happen after forgejo is deployed and healthy.
Design position (implementation team spinning up):
Mechanism — Forgejo has no cross-instance fork, but
POST /api/v1/repos/migrateis the fork-equivalent: full history lands and the repo permanently records its source (forge-level genealogy, visible in UI + API), complementing the plain-textORIGINfile. Runs in germinate AFTER the postgres-backed Forgejo is healthy (the existing re-push phase), replacing the squashed-bundle push for the mitosis repo only.3-tier fallback (keeps seeds air-gap-safe):
createdFrom+ reachability probe — parents publish mitosis publicly, no creds needed)git.open-platform.sh/plat/mitosis(the null/removed-parent case from this issue)Maintainer flow — a daughter's mitosis is a full-history migrate of its parent's: maintainers commit their own changes, and THEIR daughters migrate from them (
createdFromchains). One-time migrate by default — NOT a pull-mirror, so downstream edits are never clobbered;MITOSIS_FORK_MIRROR=1opt-in can add auto-sync later if wanted.Sequencing — lands after the 0.7.6 train merges (same
bin/germinateseam as PR #68; single-writer rule), validated by a fresh vxrail germination asserting: migrated repo carries parent history + migration source metadata, fallback tiers behave (parent-unreachable → root; both-unreachable → bundle), and ORIGIN lineage still appends.Salvage status: implementation is PUSHED (branch feat/fork-on-germinate @
29d18e7, based on the merged #68) but the team was cut by a session limit BEFORE validation — no germination ran; the leaked fork70 cluster was swept. Next: rebase onto post-train main (its base commit is now in main), run the two-tier validation (parent-fork + forced tier-3 offline) per the design comment, then PR. No PR opened yet by design.Delivered and merged (PR #72). Daughters now FORK their parent's mitosis via repo-migrate — full parent history + forge-recorded source — with the 3-tier fallback (parent → root → seed bundle) and air-gapped germination unchanged. Proven by the coldstart gate ITSELF: the CI daughter migrated from git.open-platform.sh/plat/mitosis with parent history (gate A7, run 8 green), tier RESULT line cross-checked against the forge record. Downstream maintainers get a full-history mitosis to develop on; their daughters chain from them; ORIGIN keeps the plain-text lineage on top.