[23/25] entry: deal with unexpected "Filtering content" total

Commit Message

Ævar Arnfjörð Bjarmason June 23, 2021, 5:48 p.m. UTC

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 <[e-mail]>
Signed-off-by: Ævar Arnfjörð Bjarmason <[e-mail]>
---
 entry.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Patch

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. */