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. -Peff
