]> git.ipfire.org Git - thirdparty/git.git/commit
bloom: use num_changes not nr for limit detection
authorDerrick Stolee <dstolee@microsoft.com>
Mon, 11 May 2020 11:56:13 +0000 (11:56 +0000)
committerJunio C Hamano <gitster@pobox.com>
Mon, 11 May 2020 16:33:56 +0000 (09:33 -0700)
commit2f6775f00c4b39b905e84c46b95e5a04017ec9ba
treecff6646ede19a844801e8a14f76fca85e29f8876
parent65c1a28bb60d1c17a672306c651bb402378f81b0
bloom: use num_changes not nr for limit detection

As diff_tree_oid() computes a diff, it will terminate early if the
total number of changed paths is strictly larger than max_changes.
This includes the directories that changed, not just the file paths.
However, only the file paths are reflected in the resulting diff
queue's "nr" value.

Use the "num_changes" from diffopt to check if the diff terminated
early. This is incredibly important, as it can result in incorrect
filters! For example, the first commit in the Linux kernel repo
reports only 471 changes, but since these are nested inside several
directories they expand to 513 "real" changes, and in fact the
total list of changes is not reported. Thus, the computed filter
for this commit is incorrect.

Demonstrate the subtle difference by using one fewer file change
in the 'get bloom filter for commit with 513 changes' test. Before,
this edited 513 files inside "bigDir" which hit this inequality.
However, dropping the file count by one demonstrates how the
previous inequality was incorrect but the new one is correct.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bloom.c
t/t0095-bloom.sh