Jeff King <peff@xxxxxxxx> writes: > On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > If it's smooth, the (50,1) case is slightly nicer in that it puts the >> > progress in front of the user more quickly. I'm not sure if that's >> > actually worth pushing an additional decision onto the person writing >> > the calling code, though (especially when we are just now puzzling out >> > the method for making such a decision from first principles). >> > >> > So I'd vote to drop that parameter entirely. And if 1 second seems >> > noticeably snappier, then we should probably just move everything to a 1 >> > second delay (I don't have a strong feeling either way). >> >> Sounds like a good idea to me. >> >> I've already locally tweaked Kevin's patch to use (0,2) instead of >> (0,1) without introducing the simpler wrapper. It should be trivial >> to do a wrapper to catch and migrate all the (0,2) users to a >> start_delayed_progress() that takes neither percentage or time with >> mechanical replacement. > > I was actually proposing to move (50,1) cases to the simpler wrapper, > too. IOW, drop the delayed_percent_treshold code entirely. I should have mentioned that (50,1) should also be treated just like (0,2) case--they should mean the same thing. Other oddness like 95 might merit individual consideration, and I didn't want to add (0,1) as another oddball to the mix.
