When `git range-diff` cannot match a commit between two versions of a branch, it shows the old commit as removed (`<`) and the new commit as added (`>`), and it does not show the patch contents.
This output is easy to misread as "no code changes" because the diff for that commit is effectively empty.
It really means the commits were considered unrelated and the new commit should be reviewed from scratch.
This is analogous to rename detection in `git diff`: if similarity is too low, a rename shows up as delete+add.
Example (exact SHAs from PR #34320):
B=ff338fdb53a66ab40a36e1277e7371941fc89840; A=dd76338a57b9b1169ac27f7b783d6d0d4c6e38ab; git fetch upstream $B $A
git range-diff 0ca4295f2e5f4443a1f8b3bae7cba0f6c054276f..$B 139aa4b27e4839291c83a04dcd1649c5595814ca..$A
This produced output like:
1: 4b32181dbb < -: ---------- test: add `HaveInputs` call-path unit tests
-: ---------- > 1: 277c57f0c5 test: add `HaveInputs` call-path unit tests
Even though the subject matches, the first commit had no matching diff shown.
That should be treated as "unmatched" rather than "unchanged".
If you expected a match, try increasing the creation factor so `git range-diff` searches harder:
git range-diff --creation-factor=95 <old_range> <new_range>
Current recommendation is to add a new remote fetching all PRs, but this
is resource-intensive.
Document a better way to fetch a single PR, and to update a PR which has
been force-pushed.
5801dd628d docs: Add more tips to productivity.md (gwillen)
Pull request description:
Add advice to productivity.md on:
- Using ccache to optimal effect
- The with-incompatible-bdb configure option
- Building less than the entire set of targets
ACKs for commit 5801dd:
promag:
utACK 5801dd6.
MarcoFalke:
utACK 5801dd6
Tree-SHA512: 2138acd4bf5a27ecaa9a02fb2141903d01ee199ba85ccf6a5ad6a0a4dabf4447d043108cdd86998801b0282e899f70892f9337b0b6dc59c6d1f0fccf61adb4e4
Add advice to productivity.md on:
- Using ccache to optimal effect
- The with-incompatible-bdb configure option
- Building less than the entire set of targets
Many developers have their own tools and tricks to be more productive
during their cycles, so let's document the best ones so that everyone
can benefit from them.
