Re: [PATCH v3 2/3] bundle-create: progress output control

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

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@vger.kernel.org/msg182844.html <robbat2-20190806T191156-796782357Z@orbis-terrarum.net>
> 
> 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@orbis-terrarum.net
> 
> > +--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@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]