On Tue, 6 Jan 2009, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@xxxxxxx> wrote:
> > There may indeed be line fragments sent over the sideband channel, as
> > well as the opposite which is multiple lines sent at once in a single
> > packet. If you look at sideband.c you'll find about all those cases.
>
> Thanks, that's what I thought...
>
> > In general, what you have to do is:
> >
> > - for each packet:
> > - split into multiple chunks on line breaks ('\r' or '\n')
> > - for each chunk:
> > - if last chunk didn't end with a line break, or if current
> > chunk is empty or only contains a line break, then skip printing
> > the "remote:" prefix. Otherwise print it.
> > - print the current chunk up to any line break
> > - if current chunk contains a line break and other characters then
> > print a sequence to clear the remaining of the screen line
> > - print the line break if any
>
> Hmm. I should note that C Git still screws this up sometimes. I've
> seen 1.6.1 git fetch mess up the output from repo.or.cz's sideband.
> I'm sure Pasky isn't running JGit's daemon, its too damn fast. :-)
>
> I don't have a spew of it handy, but late last week I saw it screw
> up while doing a clone off repo.or.cz.
Next time you see such things please send me a snapshot.
What is still possible and IMHO not worth the effort to fix is some
interaction between local and remote displays which, if intermixed in
some unlucky way, do screw up the final appearance. For example, if the
remote has sent a partial line, and before the remaining of it is
received/printed you actually have some local process also displaying a
line of its own. If that was to become a real issue, then the fix would
involve caching any partial line sent from the remote until the
associated line break is received.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
