Re: [PATCH v2 1/1] commit-graph: use start_delayed_progress()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 7, 2019, 04:37 UTC
- Message-ID
- <xmqqpni4s3mn.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20191106040955.GD4307@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is OK for now, though it does make me wonder if > "--progress" ought to perhaps override "delayed" in some instances, > since it's a positive signal from the caller that they're interested in > seeing progress.
I did have the same reaction after seeing the change to 5318 where the expected output from "git commit-graph write --progress" has become unreliable.
I think there are possibly three kinds of folks:
- I do not want the output smudged with any progress (e.g. I am a script);
- I want to see progress if it takes very long, but do not waste vertical screen real estate if it does not make me wait (e.g. I am an interactive user who occasionally wants a cue to leave the keyboard to grab coffee); and
- I want to see all progress (... now who am I? Taking a screenshot to write a tutorial or something???).
In the ideal world, the three choices above should probably be "--progress=(no|auto|always)" where not having any defaults to one of them (probably "auto", as the code can use isatty() to further turn it to "no").
Making "--progress" to mean "--progress=always" is OK, but it leaves no way to override an earlier --[no-]progress on the command line, which feels somewhat satisfying.
Thanks.