All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robin H. Johnson" <robbat2@gentoo.org>
To: Jeff King <peff@peff.net>
Cc: "Robin H. Johnson" <robbat2@gentoo.org>, git@vger.kernel.org
Subject: Re: [PATCH v3 2/3] bundle-create: progress output control
Date: Mon, 11 Nov 2019 07:28:55 +0000	[thread overview]
Message-ID: <robbat2-20191111T065646-317702456Z@orbis-terrarum.net> (raw)
In-Reply-To: <20191111040750.GB6379@sigill.intra.peff.net>

[-- 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 --]

  reply	other threads:[~2019-11-11  7:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1f7f0aa1e8fae54bf967ae83a160be2b30db634f.1573248640.git.gitgitgadget@gmail.com>
2019-11-10 20:41 ` [PATCH v3 1/3] bundle: framework for options before bundle file Robin H. Johnson
2019-11-10 20:41   ` [PATCH v3 2/3] bundle-create: progress output control Robin H. Johnson
2019-11-11  4:07     ` Jeff King
2019-11-11  7:28       ` Robin H. Johnson [this message]
2019-11-11  8:10         ` Jeff King
2019-11-11  9:01           ` Junio C Hamano
2019-11-10 20:41   ` [PATCH v3 3/3] bundle-verify: add --quiet Robin H. Johnson
2019-11-11  4:09     ` Jeff King
2019-11-11  2:34   ` [PATCH v3 1/3] bundle: framework for options before bundle file Junio C Hamano
2019-11-11  3:54   ` Jeff King
2019-11-11  8:46   ` Johannes Schindelin
2019-11-11  9:00     ` Junio C Hamano
2019-11-12 15:09       ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=robbat2-20191111T065646-317702456Z@orbis-terrarum.net \
    --to=robbat2@gentoo.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.