fable5-git-rebase-safety

Validates git branches after history rewrites using tree-twin content matching.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/diazMelgarejo/orama-system --skill fable5-git-rebase-safety-diazmelgarejo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fable5-git-rebase-safety
Source: https://github.com/diazMelgarejo/orama-system/tree/main/bin/orama-system/skills/fable5-git-rebase-safety
Command: npx skills add https://github.com/diazMelgarejo/orama-system --skill fable5-git-rebase-safety-diazmelgarejo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a git history rewrite (squash-merge, filter-repo, force-push), SHA-based tools like rev-list --count and merge-base falsely report branches as hundreds of commits behind or orphaned, leading to accidental branch deletion or broken merges. ## Core Features & Use Cases - Tree-Twin Scanning: Classifies every branch as MERGED, NEEDS-REANCHOR, NO-TWIN, or ORPHAN by comparing tree object hashes (%T) instead of SHAs. - Post-Rewrite Validation: Proves whether a branch's content already exists in main before merging, deleting, or force-pushing. - Granular Triage: Uses patch-id matching, PR-scoped diffs, and structural supersession checks to classify individual commits and files. - Use Case: After a squash-merge rewrites main and 14 branches appear "600 behind", run the reanchor scan to prove which branches are already merged and which need cherry-pick grafting onto new parents. ## Quick Start Run the tree-twin scan on my repository to validate which branches are safe to merge or delete after the recent history rewrite.

Frequently Asked Questions about fable5-git-rebase-safety

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate git branches after a rebase or squash-merge?

Run a tree-twin scan that compares each branch tip's tree hash (%T) against trees already in main. A matching tree proves the branch content is fully merged regardless of SHA changes, avoiding false orphan reports from rev-list or merge-base.

Why does git show my branch as hundreds of commits behind after a rewrite?

History rewrites change every commit SHA, so adjacency-based tools like rev-list --count and GitHub's behind-counter report meaningless numbers. The tree object hash stays identical when content is unchanged, making tree-twin comparison the correct test.

How do I check if two commits are the same change with different SHAs?

Use git patch-id --stable on both commits and compare the fingerprints. Patch-id ignores parent, author, and date, hashing only the diff content. Treat an empty patch-id as unknown, never as a match.

Can I use merge-base to compare branches after a force-push?

No, merge-base is unreliable across rewrites because shared ancestor SHAs no longer exist. Use tree-twin matching for branch-level checks and patch-id for commit-level equivalence instead.

What should I do before force-pushing a rewritten main branch?

Record the current origin/main SHA and use git push --force-with-lease so the push fails if remote moved unexpectedly. Run a tree-twin scan first to confirm no branches with unique work will be stranded.