On Sun, Jun 20 2021, SZEDER Gábor wrote:
> 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. This causes the failures of the tests
> 'fetch.writeCommitGraph' and 'fetch.writeCommitGraph with submodules'
> in 't5510-fetch.sh' when run with GIT_TEST_CHECK_PROGRESS=1.
>
> Fix this by passing 'i + 1' to display_progress(), like most other
> callsites do.
>
> Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx>
> ---
> commit-graph.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/commit-graph.c b/commit-graph.c
> index 2bcb4e0f89..3181906368 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -2096,7 +2096,7 @@ static void sort_and_scan_merged_commits(struct write_commit_graph_context *ctx)
>
> ctx->num_extra_edges = 0;
> for (i = 0; i < ctx->commits.nr; i++) {
> - display_progress(ctx->progress, i);
> + display_progress(ctx->progress, i + 1);
>
> if (i && oideq(&ctx->commits.list[i - 1]->object.oid,
> &ctx->commits.list[i]->object.oid)) {
I think this fix makes sense, but FWIW there's a large thread starting
at [1] where René disagrees with me, and thinks the fix for this sort of
thing would be to display_progress(..., i + 1) at the end of that
for-loop, or just before the stop_progress().
I don't agree, but just noting the disagreement, and that if that
argument wins then a patch like this would involve changing the other
20-some calls to display_progress() in commit-graph.c to work
differently (and to be more complex, we'd need to deal with loop
break/continue etc.).
1. https://lore.kernel.org/git/patch-2.2-042f598826-20210607T144206Z-avarab@xxxxxxxxx/
