[PATCH 23/25] entry: deal with unexpected "Filtering content" total
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jun 23, 2021, 17:48 UTC
- Message-ID
- <patch-23.25-e0317d7c780-20210623T155626Z-avarab@gmail.com>
- In-Reply-To
- <cover-00.25-00000000000-20210623T155626Z-avarab@gmail.com>
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@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- 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