summaryrefslogtreecommitdiff
path: root/compat/apple-common-crypto.h
diff options
context:
space:
mode:
authorLibravatar SZEDER Gábor <szeder.dev@gmail.com>2021-09-09 03:10:11 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-09-09 09:58:19 -0700
commit4011224944bf5dc6f38bce55edd5b4092ac0c930 (patch)
treeea9cd8b03fd78c00627bce3cf328249f940e1aa7 /compat/apple-common-crypto.h
parentcheckout: make delayed checkout respect --quiet and --no-progress (diff)
downloadtgif-4011224944bf5dc6f38bce55edd5b4092ac0c930.tar.xz
commit-graph: fix bogus counter in "Scanning merged commits" progress line
The final value of the counter of the "Scanning merged commits" progress line is always one less than its expected total, e.g.: Scanning merged commits: 83% (5/6), done. This happens because while iterating over an array the loop variable is passed to display_progress() as-is, but while C arrays (and thus the loop variable) start at 0 and end at N-1, the progress counter must end at N. Fix this by passing 'i + 1' to display_progress(), like most other callsites do. There's an RFC series to add a GIT_TEST_CHECK_PROGRESS=1 mode[1] which catches this issue in the 'fetch.writeCommitGraph' and 'fetch.writeCommitGraph with submodules' tests in 't5510-fetch.sh'. The GIT_TEST_CHECK_PROGRESS=1 mode is not part of this series, but future changes to progress.c may add it or similar assertions to catch this and similar bugs elsewhere. 1. https://lore.kernel.org/git/20210620200303.2328957-1-szeder.dev@gmail.com/ Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat/apple-common-crypto.h')
0 files changed, 0 insertions, 0 deletions