# Re: \[PATCH 12/25\] progress.c: add \& assert a "global\_progress" variable

- From: SZEDER Gábor \<hidden\>
- Date: 2021-09-16 19:00:53 
- List: git
- Page: https://ratatoskr.run/git/2021/09/7902711
- Thread: https://ratatoskr.run/git/2021/06/7892958/t/2.md

```text
On Wed, Jun 23, 2021 at 07:48:12PM +0200, Ævar Arnfjörð Bjarmason wrote:
> The progress.c code makes a hard assumption that only one progress bar
> be active at a time (see [1] for a bug where this wasn't the case),
> but nothing has asserted that that's the case. Let's add a BUG()
> that'll trigger if two progress bars are active at the same time.

I very much dislike the idea of any BUG() in the progress code that
can trigger outside of the test suite.

As the number of progress-related fixes clearly show, we often misuse
the progress API, and, arguably, a bug is a bug is a bug, so strictly
speaking a BUG() is not wrong here.

However, the progress line is merely a UI gimmick, not a crucial part
of Git, and none of those progress bugs affected the correctness of
the operation itself.  Worse, calling BUG() during some operations
(e.g. 'git commit-graph write', the worst offender when it comes to
progress bugs) can leave a lockfile behind, resulting in scary errors
and requiring manual cleanup in the .git directory, which is a much
worse UX than showing some bogus values or out of order progress
lines.

```