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.
