diff options
author | Johannes Sixt <j6t@kdbg.org> | 2025-08-25 21:16:12 +0200 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2025-08-25 15:50:17 -0700 |
commit | 457534d0417d047b943f76a849f256b739894ce9 (patch) | |
tree | 6a1fca9e25833ba0602aba601da4ff9739c8c4fe /builtin/range-diff.c | |
parent | f368df439b31b422169975cc3c95f7db6a46eada (diff) |
progress: pay attention to (customized) delay time
Using one of the start_delayed_*() functions, clients of the progress
API can request that a progress meter is only shown after some time.
To do that, the implementation intends to count down the number of
seconds stored in struct progress by observing flag progress_update,
which the timer interrupt handler sets when a second has elapsed. This
works during the first second of the delay. But the code forgets to
reset the flag to zero, so that subsequent calls of display_progress()
think that another second has elapsed and decrease the count again
until zero is reached. Due to the frequency of the calls, this happens
without an observable delay in practice, so that the effective delay is
always just one second.
This bug has been with us since the inception of the feature. Despite
having been touched on various occasions, such as 8aade107dd84
(progress: simplify "delayed" progress API), 9c5951cacf5c (progress:
drop delay-threshold code), and 44a4693bfcec (progress: create
GIT_PROGRESS_DELAY), the short delay went unnoticed.
Copy the flag state into a local variable and reset the global flag
right away so that we can detect the next clock tick correctly.
Since we have not had any complaints that the delay of one second is
too short nor that GIT_PROGRESS_DELAY is ignored, people seem to be
comfortable with the status quo. Therefore, set the default to 1 to
keep the current behavior.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/range-diff.c')
0 files changed, 0 insertions, 0 deletions