git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Robin H. Johnson <robbat2@gentoo.org>
Date
Nov 11, 2019, 07:28 UTC
Message-ID
<robbat2-20191111T065646-317702456Z@orbis-terrarum.net>
In-Reply-To
<20191111040750.GB6379@sigill.intra.peff.net>
On Sun, Nov 10, 2019 at 11:07:50PM -0500, Jeff King wrote:
Show 42 quoted lines
> 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)

Show 7 quoted lines
> 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
Previous: Jeff KingNext: Jeff King
Message 6 of 13 in “bundle: framework for options before bundle file”
  1. 1/3 bundle: framework for options before bundle fileRobin H. Johnson, Nov 10, 2019
  2. 3/3 bundle-verify: add --quietRobin H. Johnson, Nov 10, 2019
  3. Jeff KingNov 11, 2019
  4. 2/3 bundle-create: progress output controlRobin H. Johnson, Nov 10, 2019
  5. Jeff KingNov 11, 2019
  6. Robin H. JohnsonNov 11, 2019
  7. Jeff KingNov 11, 2019
  8. Junio C HamanoNov 11, 2019
  9. Junio C HamanoNov 11, 2019
  10. Jeff KingNov 11, 2019
  11. Johannes SchindelinNov 11, 2019
  12. Junio C HamanoNov 11, 2019
  13. Johannes SchindelinNov 12, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.