majiayu000 Orthogonalize PR
Identify independent change sets within a PR and separate them into branches.
Why This Exists
Many PRs bundle unrelated changes together. A "fix retry logic" PR might also add logging, refactor a helper, and update tests for something else. These orthogonal changes:
- Make review harder (reviewer context-switches between concerns)
- Make bisect harder (which change caused the regression?)
- Make reverts harder (can't revert just the problematic part)
By identifying orthogonal components, you can suggest splitting the PR or understand its independent pieces.
Prerequisites
Run /decompose-pr first. Orthogonalize operates on a decomposed branch where each commit represents a logical change.
Phase 1: Analyze Dependencies
Review each commit from the decomposed branch and map dependencies.
# List commits on the decomposed branch
git log --oneline <base>..HEAD
# For each commit, examine what it touches
git show --stat <commit>
git show <commit>
For each commit, identify:
- What it introduces — New types, functions, files
- What it depends on — Types/functions from other commits in this branch
- What depends on it — Later commits that use what this introduces
Build a dependency table:
| Commit | Introduces | Depends On | Depended By |
|--------|------------|------------|-------------|
| 1 | CacheEntry type | - | 2, 3 |
| 2 | Cache struct | 1 | 3 |
| 3 | Cache integration | 1, 2 | - |
| 4 | RateLimiter type | - | 5 |
| 5 | RateLimiter integration | 4 | - |
Phase 2: Identify Orthogonal Sets
Group commits into orthogonal sets — clusters with internal dependencies but no cross-cluster dependencies.
Algorithm:
- Build a graph where commits are nodes and dependencies are edges
- Find connected components — each component is an orthogonal set
- Commits with no dependencies on other branch commits are their own set
From the example above:
- Set A: Commits 1, 2, 3 (Cache feature)
- Set B: Commits 4, 5 (RateLimiter feature)
These sets are orthogonal — they don't depend on each other.
Present to user:
## Orthogonal Sets
| Set | Commits | Description | Files |
|-----|---------|-------------|-------|
| A | 1, 2, 3 | Cache feature | cache.ts, index.ts |
| B | 4, 5 | Rate limiting | limiter.ts, index.ts |
Sets A and B are independent. They touch `index.ts` in different places
but don't share types or call each other.
Get user input: They may want to name the sets differently, or may see dependencies you missed.
Phase 3: Create Branches
Create a branch for each orthogonal set.
# Start from the decomposed branch
git checkout <user>/decompose/<pr-branch>
# For each set, create a branch with just those commits
git checkout -b <user>/orthogonalize/<pr-branch>/cache <base>
git cherry-pick <commit-1> <commit-2> <commit-3>
git checkout -b <user>/orthogonalize/<pr-branch>/rate-limiter <base>
git cherry-pick <commit-4> <commit-5>
Verify each branch:
# Should build independently
# (prettier, cargo fmt, black, etc.)
# (npm run build, cargo check, make build, etc.)
If a branch doesn't build, either:
- A dependency was missed — revisit Phase 2
- The changes aren't truly orthogonal — merge the sets
Phase 4: Summarize
Present the orthogonal structure:
## Orthogonalization Complete
Original PR: #123 "Add caching and rate limiting"
Decomposed branch: user/decompose/feature-branch
Orthogonal branches:
| Branch | Commits | Description | Builds? |
|--------|---------|-------------|---------|
| user/orthogonalize/feature-branch/cache | 3 | Cache feature | Yes |
| user/orthogonalize/feature-branch/rate-limiter | 2 | Rate limiting | Yes |
**Recommendation:** These could be two separate PRs:
1. "Add response caching" (cache branch)
2. "Add rate limiting" (rate-limiter branch)
Merging in either order would work. No conflicts expected.
When Sets Aren't Worth Splitting
Sometimes orthogonal sets exist but splitting isn't worthwhile:
- Too small: A 5-line logging change isn't worth its own PR
- Conceptually unified: Author bundled them intentionally for a reason
- Review overhead: Two PRs means twice the CI, review cycles, merge conflicts
Note these cases but don't force splits. The goal is to identify orthogonality, not mandate separation.
Edge Cases
Shared base refactor: Sometimes commit 1 is a refactor that enables both Set A and Set B. Options:
- Include it in both branches (duplication, but each stands alone)
- Make it a third "foundation" set that both depend on
- Leave sets coupled if the refactor is small
File-level overlap: Two sets may touch the same file in different places. This is fine — they're still orthogonal if changes don't interact. Git can merge them.
Test coupling: Tests might span multiple sets. Options:
- Include tests with the code they test
- Create a separate "tests" set if tests are truly independent
- Accept some test duplication across branches
Anti-patterns
- Orthogonalizing without decomposing first (you need to understand the changes)
- Creating too many tiny sets (defeats the purpose)
- Missing semantic dependencies (two functions that must exist together)
- Forcing orthogonality when changes are genuinely coupled
Enter orthogonalization mode now. Confirm which decomposed branch to analyze, then begin Phase 1.