Am 21.06.21 um 00:13 schrieb Ævar Arnfjörð Bjarmason:
>
> 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/
*sigh* (And sorry, Ævar.)
Before an item is done, it should be reported as not done. After an
item is done, it should be reported as done. One loop iteration
finishes one item. Thus the number of items to report at the bottom of
the loop is one higher than at the top. i is the correct number to
report at the top of a zero-based loop, i+1 at the bottom.
There is another place: In the loop header. It's a weird place for a
function call, but it gets triggered before, between and after all
items, just as we need it:
for (i = 0; display_progress(ctx->progress), i < ctx->commits.nr; i++) {
We could hide this unseemly sight in a macro:
#define progress_foreach(index, count, progress) \
for (index = 0; display_progress(progress, index), index < count; index++)
Hmm?
René
