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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Junio C Hamano" <gitster@xxxxxxxxx>
Jeff King <peff@xxxxxxxx> 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", &signature_file,
 N_("add a signature from a file")),
 OPT__QUIET(&quiet, N_("don't print the patch filenames")),
+ OPT_BOOL(0, "progress", &show_progress,
+ N_("show progress while generating patches")),

Earlier I suggested allowing --progress="custom text" since this may be
driven as plumbing for other commands. But I don't think there's any
need to worry about it now. It can be added seamlessly later if we find
such a caller.

@@ -1752,8 +1757,12 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 start_number--;
 }
 rev.add_signoff = do_signoff;
+
+ if (show_progress)
+ 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).
--
Philip



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux