Re: [PATCH] promisor-remote: add promisor.quiet configuration option

[Tom Hughes <tom@compton.nu>]

On 23/05/2024 23:23, Junio C Hamano wrote:

> It is an interesting observation.  I thought "git blame" was quite
> bad at streaming (i.e., until it learned the origin of each and
> every line, it never produced any output the user asked for), which
> actually would make it a non issue that the output the user wanted
> gets mixed with the progress messages and other garbage.  Unless the
> user understands that "git blame" is not spending time itself, but
> is waiting for necessary blobs to be fetched from the promisor, and
> is expected to wait unusally longer than the fully local case,
> having to stare at a blank/unchanging screen would make it uneasy
> for the end-user and that is why we have progress eye-candy.

Blame actually has it's own progress message that counts the
number of lines analysed which gets interrupted by the progress
messages from the promisor.

Something like "git log -S" behaves a bit differently - it doesn't
have progress and because it's using a pager by default that causes
the promisor progress to be suppressed because stderr is no longer
a terminal but you do still get lots of background gc notifications.

> I am OK for promisor.quiet being optional, but I am torn when I
> imagine what comes next.  On one hand, I myself probably would find
> it neat to make these lazy fetches happen completely silently as if
> nothing strange is happening from the point of view of end-users
> (except for some operations may be unusually slow compared to fully
> local repository).  On the other hand, I suspect people will be
> tempted to push it to be on by default at which time it may hurt
> unsuspecting (new) users who may have been helped by progress bars.

I do agree that it's hard to know what the right thing to do is here
or even to know the full scope of the effect.

I'll update the patch to address the specific review comments.

Tom

-- 
Tom Hughes (tom@compton.nu)
http://compton.nu/