On Fri, Jul 10, 2020 at 02:09:04PM -0700, Junio C Hamano wrote: > > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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. > > > 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.
