Bitcoin Backports

[PastaPastaPasta]

Bitcoin Backports are an incredibly valuable part of Dash's development. Backporting allows us to easily implement new features, improvements and fixes as bitcoin implements them.

Current Status

• Bitcoin v0.16
• Bitcoin v0.17
• Bitcoin v0.18
• Bitcoin v0.19
• Bitcoin v0.20
• Bitcoin v0.21
• Bitcoin v22
• Bitcoin v23
• Bitcoin v24

To see detailed statistics & progress see Google Sheet tracker: https://docs.google.com/spreadsheets/d/1DnKxat0S0H62CJOzXpKGPXTa8hgoVOjGYZzoClmGSB8/edit?usp=sharing

You should use this sheet to find what PRs to backport and its commit. You should start on the current version as indicated above, and attempt to backport one of the first PRs you see which has no status text assigned.

Getting started

1. Add the bitcoin repo as remote: git remote add bitcoin git@github.com:bitcoin/bitcoin.git && git fetch bitcoin. This allows you to easily cherry-pick merges and look into logs of bitcoin without switching dirs.
2. Backport in batches of 10 PRs (or more, sometimes less, depending on amount of changes), 
3. Backport each commit found in the log with git cherry-pick -m1 . This will cherry-pick the PR in squashed mode, meaning that all commits of the PR will result in a single commit.
4. Many cherry-picks will result in merge conflicts. Use a graphical tool to solve them. Use a tool like Beyond Compare or CLion's resolve conflict tool. You may want to setup git to use it as git difftool and git mergetool.
5. Use aliases to speed up typing...you'll wonder how often you'd have to repeat commands  I have for example:
   alias gc='git cherry-pick -m1'
   alias gc2='git cherry-pick --continue'
   alias gcp='git cherry-pick'
   alias gm='git mergetool'
6. When resolving merge conflicts, watch out for code that has been moved in Dash and changed in Bitcoin. This is one of the hardest parts of backporting as it requires to manually edit source after merge-resolution is done via git mergetool. After doing this, don't forget to add the changes to the git index and finish the cherry-pick with git cherry-pick --continue
7. Some cherry-picks will result in empty git indexes, which usually indicates that the changes were already backported (or the same changes applied by us). Use git cherry-pick --abort to skip these.
8. Watch out for out-of-order backports. Some stuff was backported out-of-order and the merge conflicts for other backports might look strange. The same as in 6. applies here as you'll have to manually edit files to resolve these.
9. Some backports (mostly cleanup and refactoring) should be checked for their original intention. If for example the PR is removing all uses of some boost lib, you would have to do the same for Dash-only code. Do this in separate commits to make review easier.
10. Watch out for introductions of "Bitcoin/bitcoind/bitcoin-cli" and related strings through backports. These need to be "Dashified". Dashify in new commits on-top.
11. Some PRs do "scripted diffs" (e.g. bccb4d2). These will have a list of shell commands (usually some seds and other stuff) in commit descriptions. Instead of backporting these PRs in the usual way, run these commands by yourself and add your own commit with a reference to the original commit in the comment. In these cases it might also be better to not use git cherry-pick -m1 on the merge commit but instead cherry-pick the individual commits of the original PR + your own commit with the scripted-diff.
12. Use a good IDE!!! CLion is a very good one as it allows you to navigate through the source very fast (e.g. reliably show all uses of a method/variable/class). It also allows you to "annotate/blame" source files and navigate through different versions of files (e.g. right-click on the commit-id and "Annotate Previous Revision"). Of course, if you already know something, use what you know.
13. Run unit and integration tests locally for every batch of backports, or more frequently as you see necessary. No need to do this after every single cherry-pick, it's normally enough to do it per batch. Then, depending on the type of failures, either squash fixes into the cherry-picked commits (when you obviously missed some changes) or create new commits with the test fixes.
14. You may be faster with backporting than we are with reviews and merges  You can backport many more PRs locally in a branch than you plan to PR into dashpay/dash in the next batch. This could be your working branch with hundreds of finished backports. Then, for each batch you'd like to create a PR for, create a new branch and git cherry-pick individual backports into the new batch. After that batch is reviewed and merged, use git checkout develop && git pull && git checkout && git rebase develop to update your work branch. This will also remove commits that were successfully merged into develop and make the local branch smaller each time.
15. Backup your work branch from time to time with git tag
16. Use the gitk tool. It's probably not installed and needs to be installed. It looks like 100 years old tool and is strange to use. But its the fastest git visual tool available and offers all necessary features. You can easily navigate to individual commits and search through all commit messages and diffs.
    It can be called with the target branch/commit that you'd like to start from, which is very usefull. For example: gitk bitcoin/master and then navigate to a commit only found in bitcoin. Or directly go to the commit you'd like to inspect, e.g. with gitk bccb4d2

Feel free to reach out to @pasta | keybase.io/pasta on http://staydashy.com discord with 1:1 questions, or respond here directly.

Bounties

Contributions to Dash Core are eligible for bounties ranging from .1 Dash to 10 Dash. See https://trello.com/c/dbkj327J/86-dash-core-contributions