Re: [PATCH] Fixup no-progress for fetch & clone

From: Nicolas Pitre <nico@cam.org>
Date: Feb 24, 2007, 05:14 UTC
Message-ID: <alpine.LRH.0.82.0702240005270.29426@xanadu.home>
In-Reply-To: <7vbqjk17a8.fsf@assigned-by-dhcp.cox.net>

On Fri, 23 Feb 2007, Junio C Hamano wrote:

Show 15 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> > And it is not like if the whole thing was thrown away.  For example I 
> > think messages like
> >
> > 	remote: Writing 1234 objects.
> >
> > are good messages to have in a log file even when progress display is 
> > filtered out.  So the sideband demultiplexing is useful in that case as 
> > well.
> 
> In that case, maybe we should define a separate sideband for
> progress display?  Currently #1 (payload) and #3 (emergency
> exit) are distinct but #2 corresponds to stderr which has info
> messages and progress noise all mixed up.

And how would the remote end distinguish how to split the info from the progress noise? Teaching pack-object about another file descriptor? And what happen if pack-object is run locally in that case?

How does that solve the issue with servers (currently all of them) that don't know about the new sideband?

I think life might just be so much simpler if we just decide right now that progress noise is defined as a string ending witha '\r', and that we just toss it locally when we don't want progress noise. As a bonus this is even fully backward compatible with all existing servers.

Nicolas