Re: Bug report: 'filtering content' delayed progress message does not respect --quiet

From: Jeff King <peff@peff.net>
Date: Mar 26, 2021, 08:31 UTC
Message-ID: <YF2b8LLhE0vjc7mg@coredump.intra.peff.net>
In-Reply-To: <CABceR4ZFVW=zeSwef7_dP+TWZ29J7BUkmMEB1CzCz=et_yYS9w@mail.gmail.com>

On Sun, Mar 21, 2021 at 03:53:07PM -0500, Sean Allred wrote:

Show 13 quoted lines

> What did you do before the bug happened? (Steps to reproduce your issue)
> 
>   Called `git clone --quiet git://path/to/private/repo`
> 
> What did you expect to happen? (Expected behavior)
> 
>   Expected git to be quiet :-)  Did not expect writes to stderr/stdout.
> 
> What happened instead? (Actual behavior)
> 
>   Received output that looked like
> 
>       Filtering content:  --% (--/--), --.-- MiB | --.-- MiB/s

+cc Lars, who added this in 52f1d62eb4 (convert: display progress for filtered objects that have been delayed, 2017-08-20).

The message is in finish_delayed_checkout(), which gets only a "struct checkout" to carry the state. That has a "quiet" field, but I'm not sure it is set appropriately. E.g., builtin/checkout.c's checkout_worktree() does not set it at all, and it is unconditionally set in unpack-trees.c's check_updates().

We should obviously be respecting --quiet, but also checking isatty(2) before auto-enabling. Probably we need a separate show_progress field. For unpack-trees, I think it would get set from o->verbose_update, which is what controls the existing "Updating files" meter. For checkout.c, it probably comes from checkout_opts.show_progress.

-Peff