On Sun, Nov 10, 2019 at 11:07:50PM -0500, Jeff King wrote: > On Sun, Nov 10, 2019 at 12:41:25PM -0800, Robin H. Johnson wrote: > > > Support the progress output options from pack-objects in git-bundle's > > create subcommand. Most notably, this provides --quiet as requested on > > the git mailing list per [1] > > > > Reference: https://www.mail-archive.com/git@xxxxxxxxxxxxxxx/msg182844.html <robbat2-20190806T191156-796782357Z@xxxxxxxxxxxxxxxxxx> > > I'm glad you included the message-id here, since "182844" is useless if > mail-archive.com ever goes away. We usually just cite public-inbox for > that reason, since its URLs just use the message-id anyway: > > https://public-inbox.org/git/robbat2-20190806T191156-796782357Z@xxxxxxxxxxxxxxxxxx > > > +--progress:: > > + Progress status is reported on the standard error stream > > + by default when it is attached to a terminal, unless -q > > + is specified. This flag forces progress status even if > > + the standard error stream is not directed to a terminal. > > + > > +--all-progress:: > > + When --stdout is specified then progress report is > > + displayed during the object count and compression phases > > + but inhibited during the write-out phase. The reason is > > + that in some cases the output stream is directly linked > > + to another command which may wish to display progress > > + status of its own as it processes incoming pack data. > > + This flag is like --progress except that it forces progress > > + report for the write-out phase as well even if --stdout is > > + used. > > + > > +--all-progress-implied:: > > + This is used to imply --all-progress whenever progress display > > + is activated. Unlike --all-progress this flag doesn't actually > > + force any progress display by itself. > > + > > +-q:: > > +--quiet:: > > + This flag makes the command not to report its progress > > + on the standard error stream. > > Do we need all four of these? I copied the exact set of messages from git-pack-objects, and I do think the same set makes sense specifically to mirror pack-objects for the moment. stderr is a tty: A/(no options) - shorter output B/--quiet = no output C/--progress - shorter output D/--all-progress - longer output E/--all-progress-implied - longer output stderr is not a tty: A/(no options) - no output B/--quiet = no output C/--progress - shorter output D/--all-progress - longer output E/--all-progress-implied - no output Mapping this to a table for a moment: 1 2 A s n B n n C s s D l l E l n 1 = stderr is a tty 2 = stderr is not a tty s = short output l = long output (includes "Delta compression...", "Writing objects: ..") n = no output I think there is a lot of room to improve the behavior here, but at the risk of breaking backwards compatibility on the existing options, I think this older set of options should consistent between this and pack-objects. --pack-progress-output=[never|short|long] --pack-progress-conditional-on-stderr-tty (horrible names, but I wanted to convey the intent) > Just saying "--no-progress" would do what you want right now. I could > understand the desire for a general "--quiet" flag that implies > "--no-progress", and shuts off any other non-progress chatter as well. > There isn't any now, but it could be a future proofing thing (plus > having a "-q" option is standard). But I think we should document it > that way from the outset (though I notice you probably just lifted this > from pack-objects, IMHO it should be more clear, too). Willing to do later series to add --no-progress to this & pack-objects as consistency improvement if you'd like for future proofing (specifically --quiet would be all output whereas --no-progress would only cut out progress output). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2@xxxxxxxxxx GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Attachment:
signature.asc
Description: PGP signature
