git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
May 25, 2021, 07:39 UTC
Message-ID
<87y2c3mezw.fsf@evledraar.gmail.com>
In-Reply-To
<YKxBIP4lkoPeCYvb@nand.local>
On Mon, May 24 2021, Taylor Blau wrote:
Show 16 quoted lines
> 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.
Previous: Taylor BlauNext: Junio C Hamano
Message 15 of 18 in “t1092: use GIT_PROGRESS_DELAY for consistent results”
  1. t1092: use GIT_PROGRESS_DELAY for consistent resultsDerrick Stolee via GitGitGadget, May 24, 2021
  2. Jonathan NiederMay 24, 2021
  3. Derrick StoleeMay 24, 2021
  4. Taylor BlauMay 24, 2021
  5. Ævar Arnfjörð BjarmasonMay 24, 2021
  6. Taylor BlauMay 25, 2021
  7. Derrick StoleeMay 25, 2021
  8. Junio C HamanoMay 25, 2021
  9. Derrick StoleeMay 25, 2021
  10. Junio C HamanoMay 25, 2021
  11. Junio C HamanoMay 25, 2021
  12. Taylor BlauMay 25, 2021
  13. Junio C HamanoMay 25, 2021
  14. Taylor BlauMay 25, 2021
  15. Ævar Arnfjörð BjarmasonMay 25, 2021
  16. Junio C HamanoMay 25, 2021
  17. Junio C HamanoMay 25, 2021
  18. Junio C HamanoMay 25, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.