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

Jeff King writes: > On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote: > >> Jeff King 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 >> >

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

On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote: > Jeff King 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

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

Jeff King 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

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

On Mon, Aug 14, 2017 at 11:35:33AM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > 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

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

Junio C Hamano writes: > 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. ... which does not look too bad, but because it makes me wonder if we

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

Jeff King writes: > On Sat, Aug 12, 2017 at 09:06:18AM +0100, Philip Oakley wrote: > >> > > > + 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

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

On Sat, Aug 12, 2017 at 09:06:18AM +0100, Philip Oakley wrote: > > > > + 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

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

From: "Junio C Hamano" Jeff King writes: On Thu, Aug 10, 2017 at 02:32:55PM -0400, Kevin Willford wrote: @@ -1493,6 +1496,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) OPT_FILENAME(0, "signature-file", _file, N_("add a

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

Jeff King writes: > On Thu, Aug 10, 2017 at 02:32:55PM -0400, Kevin Willford wrote: > >> @@ -1493,6 +1496,8 @@ int cmd_format_patch(int argc, const char **argv, >> const char *prefix) >> OPT_FILENAME(0, "signature-file", _file, >> N_("add

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

On Thu, Aug 10, 2017 at 02:32:55PM -0400, Kevin Willford wrote: > @@ -1493,6 +1496,8 @@ int cmd_format_patch(int argc, const char **argv, const > char *prefix) > OPT_FILENAME(0, "signature-file", _file, > N_("add a signature from a file")), >

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

When generating patches for the rebase command if the user does not realize the branch they are rebasing onto is thousands of commits different there is no progress indication after initial rewinding message. The progress meter as presented in this patch assumes the thousands of patches to have a