[DO NOT MERGE] Experimental rebasing of a patch set

[ARR4N]

Warning

DO NOT MERGE. This is purely demonstrative as an exploration of a rebase strategy.

How this works

Follows the strategy of rebasing patch-set branches.

#7 was the first libevm functionality so I used that to act as the first "patch". It was merged as 5429fd87c8.

1. Create the equivalent of a patch0 branch:

$ git checkout 5429fd87c8
$ git switch -c arr4n/patch-0-experiment
$ git push

2. Perform the rebase:

$ git checkout -b arr4n/rebased-patch-0-experiment
$ git rebase -i geth-v1.14.11

The -i was to inspect the commits being rebased and ensure that only the #7 "patch" one was included.

3. After fixing the conflicts and adding all changes to the staging area:

$ go test ./...
$ git rebase --continue
$ git push

4. Open this PR.

Note

The conflicting files are the exact same ones that I needed to edit to make this branch work. core/vm/{contracts,evm}.go and params/config.go had conflicts during the rebase and the others had to be fixed to conform with upstream changes.

This is because the strategy results in an ambiguous history.

The strategy recommends:

$ git checkout arr4n/patch-0-experiment
$ git merge --no-ff arr4n/rebased-patch-0-experiment

however this doesn't account for the inevitable conflicts. Note that the --no-ff is redundant because there is no fast-forward path to merging and would have to be replaced with -X theirs to function as demonstrated in the diagram.

Although I don't recommend the -X theirs alternative, I pursued it for the purpose of a complete demonstration. We see that both versions of the same commit would then exist in the history, with the 500+ geth commits between them:

$ git log --graph --oneline | grep -n "chore: squash"
3:| * 154820ccd chore: squash `arr4n/libevm` into `libevm` (#7)
591:* | 5429fd87c chore: squash `arr4n/libevm` into `libevm` (#7)

Soundness check: GitHub says we are 584 commits behind, so these numbers are reasonable.

Although they both exist, a diff between them with git diff 5429fd87c 154820ccd includes all of the intermediate geth changes so we can't easily review patch updates. Inspecting only the latest one with git show 154820ccd displays the current version of the patch set, but not how it evolved. We can see this by inspecting the modifications to RunPrecompiledContract and noting that they include the *tracing.Hooks parameter, which was one of the rebasing conflicts that had to be resolved.

Adding --unified=0 to remove noisy context:

index 104d2ba81..c56c37274 100644
--- a/core/vm/contracts.go
+++ b/core/vm/contracts.go
@@ -223 +223 @@ func ActivePrecompiles(rules params.Rules) []common.Address {
-func RunPrecompiledContract(p PrecompiledContract, input []byte, suppliedGas uint64, logger *tracing.Hooks) (ret []byte, remainingGas
 uint64, err error) {
+func (args *evmCallArgs) RunPrecompiledContract(p PrecompiledContract, input []byte, suppliedGas uint64, logger *tracing.Hooks) (ret 
[]byte, remainingGas uint64, err error) {

The merge commit will always be empty with git show because of the use of -X theirs.

Note

Although I may not have exhausted all options, I can't find a straightforward way to show how the patch set was updated.

How this was tested

n/a