45133c589a970390bc10e4db4f7d9921dbaa0832 doc: clarify `git range-diff` add/delete output (Lőrinc)
Pull request description:
### Problem
Range diffs in git are useful after PR rebases, but it has an easy-to-misread failure mode: if it cannot match a commit between the old and new ranges, it will show the old commit as removed (<) and the new commit as added (>), without showing any patch contents for that commit.
It can look like there were no code changes when in reality the commit was just treated as unrelated and needs full re-review.
### Example
```bash
git fetch upstream ff338fdb53a66ab40a36e1277e7371941fc89840 dd76338a57b9b1169ac27f7b783d6d0d4c6e38ab
git range-diff ff338fdb53a6...dd76338a57b9
```
This produced output like:
```patch
1: 0ca4295f2e = 93: 139aa4b27e bench: add on-disk `HaveInputs` benchmark
2: 4b32181dbb < -: ---------- test: add `HaveInputs` call-path unit tests
-: ---------- > 94: 277c57f0c5 test: add `HaveInputs` call-path unit tests
3: 8c57687f86 ! 95: c0c94ec986 dbwrapper: have `Read` and `Exists` reuse `ReadRaw`
@@ Metadata
## Commit message ##
dbwrapper: have `Read` and `Exists` reuse `ReadRaw`
- `ExistsImpl` was removed since it duplicates `CDBWrapper::ReadImpl` (except that it copies the resulting string on success, but that will be needed for caching anyway).
+ `ExistsImpl` was removed since it duplicates `CDBWrapper::ReadImpl`.
```
Even though the subject matches, there is no diff shown because the commits did not match - the reviewer could think that only the commit message was changed.
This should be treated as **unmatched** rather than **unchanged**.
If you expected a match, you can try increasing the search effort:
```bash
git range-diff --creation-factor=95 ff338fdb53a6...dd76338a57b9
```
which would show for example:
```patch
1: 0ca4295f2e = 93: 139aa4b27e bench: add on-disk `HaveInputs` benchmark
2: 4b32181dbb ! 94: 277c57f0c5 test: add `HaveInputs` call-path unit tests
@@ Commit message
The tests document that `HaveInputs()` consults the cache first and that a cache miss pulls from the backing view via `GetCoin()`.
+ Co-authored-by: Novo <eunovo9@gmail.com>
+
## src/test/coins_tests.cpp ##
@@ src/test/coins_tests.cpp: BOOST_FIXTURE_TEST_CASE(ccoins_flush_behavior, FlushTest)
}
}
-+BOOST_AUTO_TEST_CASE(ccoins_haveinputs_cache_miss_uses_base_getcoin)
++BOOST_AUTO_TEST_CASE(ccoins_cache_behavior)
```
### Fix
This PR updates `doc/productivity.md` to raise awareness and document this pitfall and mentions `--creation-factor` as a knob to try when the output seems unexpectedly empty.
ACKs for top commit:
maflcko:
review ACK 45133c589a970390bc10e4db4f7d9921dbaa0832 🏦
Sjors:
ACK 45133c589a970390bc10e4db4f7d9921dbaa0832
rkrux:
crACK 45133c5
sedited:
ACK 45133c589a970390bc10e4db4f7d9921dbaa0832
Tree-SHA512: 52dcf6db51425a3ac9789627f80233fb1e3437f7a351acf4a761504d9917837aa1ff8c964605a842ee099fae9842946784f7603f9bffa7051429b2f04b7900be
Bitcoin Core
Setup
Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires several hundred gigabytes or more of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to several days or more.
To download Bitcoin Core, visit bitcoincore.org.
Running
The following are some helpful notes on how to run Bitcoin Core on your native platform.
Unix
Unpack the files into a directory and run:
bin/bitcoin-qt(GUI) orbin/bitcoind(headless)bin/bitcoin(wrapper command)
The bitcoin command supports subcommands like bitcoin gui, bitcoin node, and bitcoin rpc exposing different functionality. Subcommands can be listed with bitcoin help.
Windows
Unpack the files into a directory, and then run bitcoin-qt.exe.
macOS
Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
Need Help?
- See the documentation at the Bitcoin Wiki for help and more information.
- Ask for help on Bitcoin StackExchange.
- Ask for help on #bitcoin on Libera Chat. If you don't have an IRC client, you can use web.libera.chat.
- Ask for help on the BitcoinTalk forums, in the Technical Support board.
Building
The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
- Dependencies
- macOS Build Notes
- Unix Build Notes
- Windows Build Notes
- FreeBSD Build Notes
- OpenBSD Build Notes
- NetBSD Build Notes
Development
The Bitcoin repo's root README contains relevant information on the development process and automated testing.
- Developer Notes
- Productivity Notes
- Release Process
- Source Code Documentation (External Link)
- Translation Process
- Translation Strings Policy
- JSON-RPC Interface
- Unauthenticated REST Interface
- BIPS
- Dnsseed Policy
- Benchmarking
- Internal Design Docs
Resources
- Discuss on the BitcoinTalk forums, in the Development & Technical Discussion board.
- Discuss project-specific development on #bitcoin-core-dev on Libera Chat. If you don't have an IRC client, you can use web.libera.chat.
Miscellaneous
- Assets Attribution
- bitcoin.conf Configuration File
- CJDNS Support
- Files
- Fuzz-testing
- I2P Support
- Init Scripts (systemd/upstart/openrc)
- Managing Wallets
- Multisig Tutorial
- Offline Signing Tutorial
- P2P bad ports definition and list
- PSBT support
- Reduce Memory
- Reduce Traffic
- Tor Support
- Transaction Relay Policy
- ZMQ
License
Distributed under the MIT software license.