Am 20.06.21 um 22:03 schrieb SZEDER Gábor:
> RFC!! Alas, not calling stop_progress() on error has drawbacks:
>
> - All memory allocated for the progress bar is leaked.
> - This progress line remains "active", in the sense that if we were
> to start a new progress later in the same git process, then with
> GIT_TEST_CHECK_PROGRESS it would trigger the other BUG() catching
> nested/overlapping progresses.
>
> Do we care?! TBH I don't :)
> Anyway, if we do, then we might need some sort of an abort_progress()
> function...
I think the abort_progress() idea makes sense; to clean up allocations,
tell the user what happened and avoid the BUG(). Showing just
"aborted" instead of "done" should suffice here -- the explanation is
given a few lines later ("'foo' was not filtered properly").
It could be a cheesy stop_progress_msg() wrapper that temporarily sets
test_check_progress to zero..
René
