summaryrefslogtreecommitdiff
path: root/Documentation/git-blame.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-12-04 17:05:23 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-12-04 14:22:17 -0800
commitee85e41af3f87afedd9fba63617e74713449240c (patch)
tree9e2534a227141cf4244bf9a076d3f1fedcc33b7d /Documentation/git-blame.txt
parentGit 2.15 (diff)
downloadtgif-ee85e41af3f87afedd9fba63617e74713449240c.tar.xz
progress: set default delay threshold to 100%, not 0%
Commit 8aade107dd (progress: simplify "delayed" progress API, 2017-08-19) dropped the parameter by which callers could say "show my progress only if I haven't passed M% progress after N seconds". The intent was to just show nothing for 2 seconds, and then always progress after that. But we flipped the logic in the wrapper: it sets M=0, meaning that we'd almost _never_ show progress after 2 seconds, since we'd generally have made some progress. This should have been 100%, not 0%. We were fooled by existing calls like: start_progress_delay("foo", 0, 0, 2); which behaved this way. The trick is that the first "0" there is "how many items total", and there zero means "we don't know". And without knowing that, we cannot compute a completed percent at all, and we ignored the threshold parameter entirely! Modeling our wrapper after that broke callers which pass a non-zero value for "total". We can switch to the intended behavior by using "100" in the wrapper call. Reported-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/git-blame.txt')
0 files changed, 0 insertions, 0 deletions