Re: [PATCH v2 1/2] format-patch: have progress option while generating patches

Jeff King [off-list ref] writes:

On Sat, Aug 12, 2017 at 09:06:18AM +0100, Philip Oakley wrote:

quoted

quoted

quoted

quoted

+ progress = start_progress_delay(_("Generating patches"), total, 0, 1);

I don't really have an opinion on a 1 second delay versus 2. I thought
we used 2 pretty consistently, though grepping around I do see a couple
of 1's. It probably doesn't matter, but just a curiosity.

...
Here we're just talking about calls to start_progress_delay(), and how
long it waits before deciding that the operation is slow enough to show
progress. Blame, rename detection, and checkout use 1 second. Prune,
prune-packed, and connectivity checks all use 2 seconds. I doubt it
matters all that much, but presumably the purpose in all is "how long
before a user starts to wonder if things are actually happening", which
is probably command-independent.

I feel comfortable moving forward, basing our decisions on the
assumption that the "delay before the user wonders is independent of
the command" without anybody actually proving it.

Even though I think that it is natural for people to expect longer
delay from some operation than others (due to some chicken-and-egg
reasons), trying to scientifically measure and to come up with
different delay value that suited for each and every operation is
waste of our brain cycles.

Perhaps we may want to replace the calls to progress_delay() with a
call to a simpler wrapper that does not let the callers give their
own delay threashold to simplify the API.