Trim overengineered docs and ADR
Remove redundant step-by-step subsections from workflow guide (the table already covers it), tighten ADR-011 alternatives, and remove version pins that go stale. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -15,13 +15,9 @@ This is a legitimate subrepo workflow — teams merge staging branches into main
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
1. **Fail and log**: The pre-v1.3 behavior. Leaves the sync stuck until someone manually intervenes. Bad for unattended cron-based sync.
|
||||
|
||||
2. **Squash all commits into one**: Create a single `commit-tree` with the diff between josh-filtered base and subrepo HEAD. Simple but destroys all commit granularity — 10 unrelated commits appear as one blob on the monorepo PR.
|
||||
|
||||
3. **Rewrite subrepo history**: Rebase or filter-branch the subrepo to remove problematic merges. Breaks the sync relationship with the monorepo (josh's SHA mapping becomes invalid) and forces all developers to re-clone.
|
||||
|
||||
4. **Linearize: cherry-pick regular commits, squash only merges**: Walk the human commits in order, cherry-pick non-merge commits as-is, and use `cherry-pick -m 1` for merge commits. Preserves individual commit granularity for regular commits; only the problematic merge commits lose their multi-parent structure.
|
||||
1. **Squash all commits into one**: Simple but destroys all commit granularity.
|
||||
2. **Rewrite subrepo history**: Breaks josh's SHA mapping, forces all developers to re-clone.
|
||||
3. **Linearize: cherry-pick regular commits, squash only merges**: Preserves individual commit granularity; only merge commits lose their multi-parent structure.
|
||||
|
||||
## Decision
|
||||
|
||||
@@ -59,10 +55,4 @@ When the direct push through josh-proxy fails, fall back to option 4: linearize
|
||||
|
||||
**Negative:**
|
||||
- Merge commit semantics are lost on the monorepo side (they appear as regular commits)
|
||||
- If a merge commit's changes conflict with a prior cherry-picked commit during linearization, the diff-apply fallback may produce a subtly different result than the original merge resolution
|
||||
- Adds complexity to the reverse sync path (two code paths: direct push and linearize fallback)
|
||||
|
||||
**Risk mitigation:**
|
||||
- The direct push is always tried first — linearization only activates when josh rejects the push
|
||||
- The monorepo PR is still reviewed by humans before merging
|
||||
- The original commit SHAs are listed in the PR body for cross-referencing
|
||||
|
||||
Reference in New Issue
Block a user