Rebase foundation: clean upstream ancestry + repeatable workflow + 2.x conflict map#344
Open
Richard1048576 wants to merge 5 commits into
Open
Rebase foundation: clean upstream ancestry + repeatable workflow + 2.x conflict map#344Richard1048576 wants to merge 5 commits into
Richard1048576 wants to merge 5 commits into
Conversation
…lict map Establishes the foundation for migrating Gravity-reth onto upstream reth 2.x and for making every *future* rebase cheap. Root cause of past pain: the fork's git ancestry to upstream is broken (reth trees were imported as squashed commits, so upstream tags are not ancestors of main → `git rebase` replays garbage). Fix: re-anchor the fork tree onto the real upstream v1.8.3 tag (preserved as tag gravity-base/v1.8.3-clean-ancestry), restoring clean ancestry so `git rebase --onto <new> <base>` works from now on. Adds: - docs/design/upstream-rebase-workflow.md — why rebases were painful, the one-time re-anchor fix, the recurring workflow, the reth release-branch `--onto` gotcha, and the durable fix (shrink the inline-modification surface by moving Gravity logic into owned crates / extension traits). - docs/design/rebase-2.x-conflict-map.md — measured trial-rebase result: 111 conflicting files (28 substantive / 43 medium / 40 mechanical), subsystem heatmap, consensus-critical cluster, and a 7-PR landing sequence. - scripts/rebase-upstream.sh — wraps the correct `--onto` form, guards that the base tag is a real ancestor, auto-backups, and prints a categorized conflict map. No auto-resolve, no push. No reth source changes in this PR. The actual conflict resolution + revm 29→38 fork bump are the follow-up PRs (sequence in the conflict map doc §4).
Contributor
|
Your PR title doesn't follow the Conventional Commit guidelines. Example of valid titles:
Usage:
Breaking Changes Breaking changes are noted by using an exclamation mark. For example:
Help For more information, follow the guidelines here: https://www.conventionalcommits.org/en/v1.0.0/ |
Evaluation of the reth-2.x critical-path dependency (Galxe/revm). Key findings: - Gravity's revm fork = 2 semantic commits over upstream revm 29. - fee-charge-disable: upstream adopted it natively (optional_fee_charge feature) → DROP Gravity's version on forward-port. - lazy-reward: not upstreamed; the real port (~20 files threading ResultAndReward + is_lazy_reward through handler/inspector). This is essentially the entire remaining fork delta. - Trial rebase onto revm 38: small Gravity edits landing in heavily-rewritten upstream files (op-revm/handler.rs: +1006 upstream vs 10 Gravity). Difficulty is API-shape understanding, not volume. - Net: the "9-major revm bump" long pole collapses to porting ONE consensus-critical feature + adopting one upstream feature. Doc kept in gravity-reth (not the revm fork) to keep the revm fork minimal — every Gravity line in revm conflicts on the next bump.
…lant PR 1 (the 4 dependency forks) is complete and tested — the reth-2.2.0 transplant is now unblocked. Records: - §6: all 4 Galxe forks done with branches + test counts (revm v38.0.0-gravity 420, alloy-evm v0.34.0-gravity 51, grevm feat/revm-38 14, revm-inspectors v0.39.0-gravity 42), plus the git-tip-vs-crates.io version-genealogy lesson that determined every fork's base commit. - §7: ready-to-paste [patch.crates-io] redirecting all revm-family crates to the Galxe forks (op-revm intentionally omitted; MSRV 1.93). - §8: note that reth is all-or-nothing to compile, so the 111-file transplant should be a dedicated effort gated on Phase-6 state-root parity, not expected to produce intermediate green builds.
… merge Ran the full cherry-pick of the re-anchored foundation onto upstream v2.2.0 and triaged all 111 conflicts (§9): - 272 files apply clean (owned crates + non-overlapping edits) - 81/111 conflicts resolve mechanically to upstream (take-HEAD): Gravity v1.8.3-era code upstream evolved, or edits v2.2.0 already adopted (e.g. triev2 field). Auto-classified by absence of Gravity markers in the per-file diff. + 3 DU deletions. - 30/111 need a real merge, ranked by size. The irreducible hard core is just ~5 deep storage/engine files (database/provider 322, persistence 217, tree/mod 193, tree/tests 175, static_file 126) — Gravity's storage + pipe-exec integration vs v2.2.0's rewritten internals. These are flagged for author-pairing + Phase-6 state-root verification and explicitly NOT guessed (silent-chain-halt risk). Net: the transplant is confirmed bounded + tractable — bulk is mechanical, hard core is ~5 files. Reproduce commands included.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Goals (per request)
This PR delivers the foundation + process for both. It contains no reth source changes — the actual conflict resolution + revm fork bump are scoped as follow-up PRs (sequence below). Safe to review/merge independently.
What was found
d620fd0e "merge reth-v1.8.3"is single-parent, not a real merge), so upstream tags aren't ancestors ofmainandgit rebasereplays garbage.The fix (in this PR)
v1.8.3tag → taggravity-base/v1.8.3-clean-ancestry. This restores clean git ancestry sogit rebase --onto <new> <base>works. Once the 2.x rebase lands,mainwill havev2.2.0as a real ancestor and this never needs doing again.scripts/rebase-upstream.sh— wraps the correct--ontoform (reth cuts maintenance releases on side branches, so plaingit rebase <tag>picks the wrong base — discovered + handled here), guards the base tag, auto-backups, prints a categorized conflict map.git rebase --onto v2.2.0 v1.8.3: 111 conflicting files (28 substantive / 43 medium / 40 mechanical), subsystem heatmap, consensus-critical cluster flagged.Files
docs/design/rebase-to-reth-2.x-plan.mddocs/design/upstream-rebase-workflow.mddocs/design/rebase-2.x-conflict-map.mdscripts/rebase-upstream.shFollow-up PR sequence (in conflict-map §4)
PR 1 revm/grevm/alloy-evm fork bumps → PR 2 scaffolding compiles → PR 3 execution/EVM → PR 4 engine → PR 5 storage/trie/stages → PR 6 periphery+tests → PR 7 mainnet-block-replay state-root verification.
Open decisions for the team (plan doc §9)
Not done here (deliberately)
No conflict resolution, no dependency bump, no compile — those need the revm fork ready + a compile/test loop, and consensus-critical files (state-root: merkle stage, trie, evm execute) must not be blind-merged. Tracked as the follow-up PRs.
🤖 Generated with Claude Code