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

From: Jeff King <peff@peff.net>
Date: Aug 13, 2017, 04:39 UTC
Message-ID: <20170813043940.muj7z3dvl3nh4k6a@sigill.intra.peff.net>
In-Reply-To: <EA124B72FA7542DBA1C31213235F1B94@PhilipOakley>

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

Show 15 quoted lines

> > > > + 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.
> > 
> > Yeah, I also thought 2-second was what we used by default.  Perhaps
> > we would want to bring others in line?
> 
> <bikeshed> Surely the choice should depend on the purpose of the delay. IIRC
> the 1 second between patches on the formal 'sent' time was simply to ensure
> the patches had the right sequence. Delays for warnings and progress have
> different purposes, so I think it's more about the purpose than
> standardising the time (along with expectations [least surprise] if other
> messages are displayed).

I think you're confusing two unrelated things. There's a 1-second fake time-advance on patches, but that's done by send-email, not format-patch.

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.

-Peff