Re: [PATCH 1/2] progress: create progress struct in 'verbose' mode

From: Emily Shaffer <emilyshaffer@google.com>
Date: Jul 10, 2020, 22:00 UTC
Message-ID: <20200710220003.GG3189386@google.com>
In-Reply-To: <xmqqpn93rsb3.fsf@gitster.c.googlers.com>

On Fri, Jul 10, 2020 at 02:09:04PM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> 
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > So to make sure I understand this right, we'll collect traces regardless
> > if it's enabled, but we'll still honor the --quiet flag if the user
> > doesn't want to see them?  If so, I'm definitely in favor of this
> > change.
> 
> Hmph, if we know we won't be emitting, why spend cycles to collect
> traces in the first place?  Does it make the code simpler to follow
> or something?  As long as it is done when the user requests a trace
> to be taken, I do not care about the wasted cycles too much, I think ;-)

Maybe then I did misunderstand brian.

With this series, traces will always be emitted to location where GIT_TRACE2_EVENT indicates, or default location. Like before, if the user asks for --quiet or equivalent, the user will not see "Resolving deltas... (4/30)" in their stderr.

Before this series, when a user indicated --quiet or equivalent, the traces were not emitted to GIT_TRACE2_EVENT's location, because the progress struct was not created.

I figured brian was saying "we'll still honor the --quiet flag if the user doesn't want to see ["Resolving deltas...blah blah" in their stderr]", and that is true. The traces will be logged but the user-facing output on stderr will be suppressed.

Show 9 quoted lines

> 
> > I was worried when I read the cover letter that we'd display
> > them to the user regardless, but from reading the patch and the commit
> > message, it seems I misunderstood.
> >
> > I think the making the verbose flag a parameter simplifies the code
> > nicely and puts the rendering decision in the right place.
> 
> OK.