So that we don't end up with a variety of different styles of backporting,
this is an attempt at a rough guide for backporting.
Details
- Reviewers
deadalnix jasonbcox matiu - Group Reviewers
Restricted Project - Commits
- rSTAGING6bde9a61e0f8: Start a guide regarding how to backport code to Bitcoin-ABC
rABC6bde9a61e0f8: Start a guide regarding how to backport code to Bitcoin-ABC
Read the document
Diff Detail
- Repository
- rABC Bitcoin ABC
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
doc/backporting.md | ||
---|---|---|
14 ↗ | (On Diff #2579) | Do you have any tips for identifying which changes are worth backporting? I have the most trouble identifying which are valuable/worth it. |
21 ↗ | (On Diff #2579) | Not all users have SSH keys setup with github. It may be worth using https://github.com/bitcoin/bitcoin.git instead. |
doc/backporting.md | ||
---|---|---|
14 ↗ | (On Diff #2579) | Well, depends on the subject. Like I was looking at changes specifically to the test framework. That allows other backports of main-code changes to go in easily. (because they usually change a few lines in the test framework too) |
Nice ! Thanks for putting this together.
doc/backporting.md | ||
---|---|---|
11 ↗ | (On Diff #2586) | This guide should apply to any Bitcoin fork (BU/Xt, etc). |
13 ↗ | (On Diff #2586) | Add the tagging command? git tag -a fork-commit 964a185 -m 'Where the fun started'? |
63 ↗ | (On Diff #2586) | Is there any convension for branch name? Like backport/pr1235? |
doc/backporting.md | ||
---|---|---|
63 ↗ | (On Diff #2586) | You can do whatever you'd like for your own convenience. It doesn't affect anything in phabricator. It's probably a wise idea to name them in numerical order -- I get out of whack otherwise. |