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
0git fetch upstream ff338fdb53a66ab40a36e1277e7371941fc89840 dd76338a57b9b1169ac27f7b783d6d0d4c6e38ab
1git range-diff ff338fdb53a6...dd76338a57b9
This produced output like:
01: 0ca4295f2e = 93: 139aa4b27e bench: add on-disk `HaveInputs` benchmark
12: 4b32181dbb < -: ---------- test: add `HaveInputs` call-path unit tests
2-: ---------- > 94: 277c57f0c5 test: add `HaveInputs` call-path unit tests
33: 8c57687f86 ! 95: c0c94ec986 dbwrapper: have `Read` and `Exists` reuse `ReadRaw`
4@@ Metadata
5## Commit message ##
6 dbwrapper: have `Read` and `Exists` reuse `ReadRaw`
7
8- `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).
9+ `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:
0git range-diff --creation-factor=95 ff338fdb53a6...dd76338a57b9
which would show for example:
01: 0ca4295f2e = 93: 139aa4b27e bench: add on-disk `HaveInputs` benchmark
12: 4b32181dbb ! 94: 277c57f0c5 test: add `HaveInputs` call-path unit tests
2@@ Commit message
3
4 The tests document that `HaveInputs()` consults the cache first and that a cache miss pulls from the backing view via `GetCoin()`.
5
6+ Co-authored-by: Novo <eunovo9@gmail.com>
7+
8 ## src/test/coins_tests.cpp ##
9 @@ src/test/coins_tests.cpp: BOOST_FIXTURE_TEST_CASE(ccoins_flush_behavior, FlushTest)
10 }
11 }
12
13-+BOOST_AUTO_TEST_CASE(ccoins_haveinputs_cache_miss_uses_base_getcoin)
14++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.
