unforklisted

# Unfork A long-diverged fork is two codebases wearing one name. The naive `git merge upstream/main` produces a conflict wall and a history nobody can audit. Your job is the opposite: figure out what the fork's divergence *actually consists of*, then rebuild only the still-valuable part on top of current upstream as clean, explainable commits. **Safety first:** all work happens on a new branch. Never force-push, never rewrite the fork's existing branches, never discard the old branch — it remains the archive until the user retires it. ## Phase 1 — Map the divergence - Fetch upstream; find the merge-base; count ahead/behind. - List every fork-side commit since the base. If the fork has merge commits from previous partial syncs, flatten your view to *effective changes* (diff-based, not commit-count-based). - Summarize what upstream did meanwhile at feature level (releases, big refactors, renames) — this is the terrain the surviving patches must land on. ## Phase 2 — Sentence every fork commit Classify each fork-side change: - **`ABSORBED`** — upstream has the identical/equivalent change. Detect with `git cherry` / patch-id first, but that only catches textual equivalence — also check *semantic* absorption: the bug it fixed has an upstream fix in different words. Drop these. - **`SUPERSEDED`** — upstream solved the same problem differently. Drop the fork's version; verify the upstream solution actually covers the fork's use case, and note the gap if it doesn't. - **`ALIVE