The "Filtering content" end total does not match the expected total in cases such as the 'missing file in delayed checkout' test in 't0021-conversion.sh'. If we encounter errors we can't accurately estimate the end state of the progress bar. This is because the test involves a purposefully buggy filter process that doesn't process any paths, so the progress counter doesn't have a chance to reach the expected total. See the preceding commit for why we'd want a stop_progress_early() in this case, as opposed to leaking memory here, or not providing a "total" estimate to begin with. Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> --- entry.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/entry.c b/entry.c index bc4b8fcc980..e79a13daa51 100644 --- a/entry.c +++ b/entry.c @@ -232,7 +232,10 @@ int finish_delayed_checkout(struct checkout *state, int *nr_checkouts) } string_list_remove_empty_items(&dco->filters, 0); } - stop_progress(&progress); + if (!errs && !dco->paths.nr) + stop_progress(&progress); + else + stop_progress_early(&progress); string_list_clear(&dco->filters, 0); /* At this point we should not have any delayed paths anymore. */ -- 2.32.0.599.g3967b4fa4ac
