Trivial tree merge #5731

Here's merge attempt #1 from the trivial tree. Though the changes are obviously trivial, I'd like to end up with a functional work-flow for merging such trees, so that the process may eventually be useful for other subsystems as well. Here's my approach so far:

• User PRs into the trivial-next branch. Actually for now most are PRing into the Bitcoin tree and I poach them, but this could change after documenting the changes.
• The trivial tree follows master, and often does upstream merges in order to stay sync'd up. Whenever pulling in a PR that has a tip higher than the current trivial-next tip, I merge from upstream first, then merge the PR. That allows for conflicts against master to be resolved before bringing in the new changes. Also, I ensure that 'git rerere' is enabled first, so that my conflict resolutions are recorded.
• I simultaneously maintain a 'trivial-rebased' branch which is essentially staging for a merge into master. After merging in a PR, I checkout this branch, reset to trivial-next, then rebase onto origin/master. The previously-recorded resolutions are re-used, so there should be no need for manual conflict resolution here if the previous steps were done correctly.
• PR into master. After merge, trivial-rebased can be reset to trivial-next, and the cycle starts over. Since trivial-next always follows master and merges from upstream rather than rebasing, users aren't required to do force-pulls or do anything else out of the ordinary.

Written out, that may sound a bit complicated, but after a few merges it's actually quite brainless.

One complaint -- "remove sig_canonical.json and sig_noncanonical.json" commit description does not say why it is being removed. Needs more explanation.

Everything else: ut ACK

@jgarzik see #5491 for the discussion/explanation about that

Binary analysis:

Concluding from this, binary changes happened in

• 91a9fe0: One-byte change in string table in rpcwallet.o 2e204966 206e6f74 2070726f 76696465 . If not provide to 2e206966 206e6f74 2070726f 76696465 . if not provide (ACK)
• 5262fde:

 .../src/libbitcoin_common_a-chainparams.o          | Bin 546336 -> 546336 bytes
 .../src/libbitcoin_common_a-core_read.o            | Bin 662552 -> 662552 bytes
 .../src/libbitcoin_common_a-keystore.o             | Bin 400744 -> 400744 bytes
 .../src/libbitcoin_common_a-protocol.o             | Bin 83600 -> 83600 bytes
 .../src/libbitcoin_server_a-alert.o                | Bin 1439800 -> 1439800 bytes
 .../src/libbitcoin_server_a-init.o                 | Bin 5660920 -> 5660920 bytes
 .../src/libbitcoin_server_a-main.o                 | Bin 9025208 -> 9025048 bytes
 .../src/libbitcoin_server_a-miner.o                | Bin 1262288 -> 1262288 bytes
 .../src/libbitcoin_server_a-net.o                  | Bin 5019160 -> 5019128 bytes
 .../src/libbitcoin_server_a-pow.o                  | Bin 77768 -> 77768 bytes
 .../src/libbitcoin_server_a-rpcmining.o            | Bin 1753176 -> 1753176 bytes
 .../src/libbitcoin_server_a-rpcrawtransaction.o    | Bin 2656296 -> 2656296 bytes
 .../src/libbitcoin_server_a-txdb.o                 | Bin 762384 -> 762384 bytes
 .../src/libbitcoin_server_a-txmempool.o            | Bin 1517992 -> 1517992 bytes
 .../src/libbitcoin_wallet_a-db.o                   | Bin 531440 -> 531440 bytes
 .../src/libbitcoin_wallet_a-rpcwallet.o            | Bin 3074120 -> 3074120 bytes
 .../src/libbitcoin_wallet_a-wallet.o               | Bin 5892408 -> 5892408 bytes
 .../src/libbitcoin_wallet_a-walletdb.o             | Bin 3362264 -> 3362264 bytes
 .../primitives/libbitcoin_common_a-transaction.o   | Bin 293376 -> 293376 bytes
 .../src/script/libbitcoin_common_a-interpreter.o   | Bin 336824 -> 336824 bytes
 .../src/script/libbitcoin_common_a-sign.o          | Bin 419264 -> 419264 bytes
 .../src/script/libbitcoin_common_a-standard.o      | Bin 482480 -> 482480 bytes

I verified all these changes are in .data sections, no code changes, but had no time to investigate deeper exactly what data is affected. Coupled with review of the source code diff to confirm these are just message changes -> ACK.

This was missing the final resolution of #5730

Let's leave that for next trivial merge.

@jgarzik: I think that's actually a point worth addressing in the workflow. Ideally all changes would be explained, but often they depend on the original PR. For the next merge, I'll look into grabbing the PR description, since it won't necessarily be coming from the bitcoin repo. @laanwj Thanks for the thorough review.

@theuni As @gmaxwell and I have pointed out in the past, what matters is what goes into the git repo and appears in the git history.

Forcing people to perform research just to figure the "why" of a commit is a sign of a broken commit description (and broken process).

The trivial tree should not be dropping crucial information.

@jgarzik Sorry if I wasn't clear. By "grabbing the PR description", i meant adding it to the commit message so that nothing is lost when going upstream. I agree with you entirely.

Indeed, adding a link to the original pull request to the commit descriptions would make sense. I also do this when backporting to a branch.

s/link/description/

Can't assume GitHub will always be here.

Discussed this quickly on IRC. The issue is that I didn't demand a better commit message that can stand on its own for 'git log' purposes. Noted.

Edit: and obviously the PR link is a good idea regardless. I'll be doing that from now on as well.

@luke-jr If that's what you're afraid of, we have a mirror of all gh metadata (including issues and all discussions) for this repository here, thanks to @zw: https://github.com/zw/bitcoin-gh-meta By keeping a local clone of that repository, we can keep everything backed up.