Re: [PATCH v4] checkout: add --progress option

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 1, 2015, 19:29 UTC
Message-ID: <CAPig+cQvsXMqAzV_59sZdqDEh_SRfOMh+BY3XLmzSPdfWwugdg@mail.gmail.com>
In-Reply-To: <20151101191902.GA19594@sigill.intra.peff.net>

On Sun, Nov 1, 2015 at 2:19 PM, Jeff King <peff@peff.net> wrote:

Show 16 quoted lines

> On Sun, Nov 01, 2015 at 12:52:57PM -0500, Eric Sunshine wrote:
>> > +--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.
>>
>> What this kind of implies, but neglects to say explicitly, is that the
>> logic implemented by this patch also overrides --quiet. It probably
>> should say so explicitly.
>
> I was the one who suggested originally that --progress should override
> --quiet[1]. However, that was just based on what I thought was
> reasonable. I didn't look at what clone or other commands do.
> Consistency between commands is probably more important than any
> particular behavior.

I did check git-clone during my v4 review, and --progress does override --quiet (see transport.c:transport_set_verbosity()), so your suggestion to make --progress override --quiet in git-checkout at least keeps it consistent.

Aside: Specifying both --quiet and --progress with git-clone doesn't
give great results since (it seems) that no flushing is done until the
newline is emitted, thus you only see the end result rather than a
running progress meter.

> [1] To be honest, this is kind of a crazy corner case anyway. It was
> more just that it has to do _something_.

An alternative would be to error out stating that --quiet and --progress are mutually exclusive.