chore(release): record master merge into release_v4.8.2#6869
Merged
lvs0075 merged 12 commits intoJul 9, 2026
Merged
Conversation
…,version code:18636 (tronprotocol#6542)
New workflows: - pr-build.yml: multi-OS build matrix (macOS, Ubuntu, RockyLinux, Debian11) and changed-line/overall coverage gate - pr-check.yml: PR title/body lint + Checkstyle - pr-reviewer.yml: scope-based reviewer auto-assignment - pr-cancel.yml: cancel in-progress runs when PR is closed unmerged - system-test.yml: spin up FullNode and run the system-test suite Existing workflows: - codeql.yml: bump to v4/v5 actions, switch to manual build-mode with JDK 8, add paths-ignore for docs-only changes - math-check.yml: bump checkout/upload-artifact/github-script versions
…ersion code:18643
317787106
approved these changes
Jul 9, 2026
lvs0075
approved these changes
Jul 9, 2026
xxo1shine
approved these changes
Jul 9, 2026
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
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.
Summary
This PR records
masteras merged intorelease_v4.8.2using anoursmerge commit.The release branch had already absorbed or superseded the relevant master-side changes via prior synchronization commits, but the Git history did not include
masteras a merge parent. As a result, attempting to mergemasteragain produced many stale conflicts.This PR only updates Git history:
mastercommita79693e450as a parent ofrelease_v4.8.2release_v4.8.2tree unchangedCommand Used
git merge -s ours --no-ff master -m "chore: record master merge into release_v4.8.2"Verification
History-only invariant
Results:
git diff --stat HEAD^1 HEADis emptygit merge-base --is-ancestor master HEADexits successfullyNote: with
-s ours, the empty diff is true by construction. It confirms this PR changes no files, but it does not by itself prove that master-side changes were already absorbed. That was verified separately.Content check
The master parent of this merge commit is
HEAD^2, and the pre-merge release parent isHEAD^1.Those master-side commits were checked against the release tree:
feat(vm): optimize the check for ModExpis present viaMUtil.checkCPUTimeForModExp()feat(vm): optimize the check for create2is present viaMUtil.checkCPUTimeForCreate2()feat(*): disable exchange transactionis present viaisExchangeTransaction()inManager.javatest(vm): add tests for create2/modExp checksis present viaCreate2ModExpForkTest.javafeat(config): fix git.properties NPEis present via the null guard inArgs.javasystem-test.ymlwas replaced byintegration-test-single-node.ymlandintegration-test-multinode.ymlMerge release_v4.8.1 to masterare superseded by the 4.8.2 release stateSpot-check commands used:
Result: the master-side changes are already present in the release tree or have been replaced by newer release-branch equivalents.
Future Sync Guidance
To avoid this issue in future
master-> release branch syncs, preserve the merge parent instead of using squash, cherry-pick-only, or manually copied changes.Recommended flow:
If conflicts occur, resolve them normally and commit the merge. This keeps Git aware that
masterhas already been merged into the release branch.If the master-side changes have already been absorbed or superseded by release-branch commits, and the only missing piece is Git history, use a history-only merge after verification:
git merge -s ours --no-ff origin/master -m "chore: record master merge into release_v4.8.2" git diff --stat HEAD^1 HEADDo not rely on the empty diff alone as the safety check. For an
oursmerge, it is empty by construction. First confirm each source-branch change is already present or superseded.On GitHub, use Create a merge commit for this type of branch-synchronization PR. Avoid Squash and merge, otherwise Git will not record the source branch as merged, and the same stale conflicts can reappear later.
Testing
Not run. This is a history-only merge commit with no file content changes.