Re: [PATCH] t1092: use GIT_PROGRESS_DELAY for consistent results

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, May 24 2021, Taylor Blau wrote:

> On Tue, May 25, 2021 at 12:57:52AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, May 24 2021, Taylor Blau wrote:
>>
>> > But I don't think this isolated instance should push in the direction of
>> > adding support for either of the above, regardless of how easy it might
>> > be.
>>
>> I don't see why we wouldn't just tweak GIT_PROGRESS_DELAY to support -1
>> or something for "inf".
>
> Ironically, I think that this already works, since we parse the value of
> GIT_PROGRESS_DELAY as unsigned, and don't bother checking for if the
> input is negative (since we eventually call git_parse_unsigned(), which
> doesn't have any extra checks other than for overflow).
>
> So we silently convert -1 to 2^64-1, and call it a day.

Well yes, it works in the sense that instead of arbitrary big value for
delay we have the biggerest and largerest value we can manage :)

I mean why do just that when we can also do this:

diff --git a/progress.c b/progress.c
index 680c6a8bf93..191c62cbbfb 100644
--- a/progress.c
+++ b/progress.c
@@ -252,7 +252,13 @@ void display_progress(struct progress *progress, uint64_t n)
 static struct progress *start_progress_delay(const char *title, uint64_t total,
 					     unsigned delay, unsigned sparse)
 {
-	struct progress *progress = xmalloc(sizeof(*progress));
+	struct progress *progress;
+
+	/* GIT_PROGRESS_DELAY=-1 */
+	if (delay == (unsigned)-1)
+		return NULL;
+
+	progress = xmalloc(sizeof(*progress));
 	progress->title = title;
 	progress->total = total;
 	progress->last_value = -1;

Which will cause the progress code to abort early in that case, and IMO
is less magical if we're going to have this GIT_PROGRESS_DELAY=-1 in the
codebase and relying on the wrap-around of -1.