aboutsummaryrefslogtreecommitdiff
path: root/sideband.c
Commit message (Collapse)AuthorAge
* recv_sideband: Bands #2 and #3 always go to stderrJohannes Sixt2009-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | This removes the last parameter of recv_sideband, by which the callers told which channel bands #2 and #3 should be written to. Sayeth Shawn Pearce: The definition of the streams in the current sideband protocol are rather well defined for the one protocol that uses it, fetch-pack/receive-pack: stream #1: pack data stream #2: stderr messages, progress, meant for tty stream #3: abort message, remote is dead, goodbye! Since both callers of the function passed 2 for the parameter, we hereby remove it and send bands #2 and #3 to stderr explicitly using fprintf. This has the nice side-effect that these two streams pass through our ANSI emulation layer on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* improve handling of sideband message displayNicolas Pitre2008-09-03
| | | | | | | | | | | | | Currently the code looks for line break characters in order to prepend "remote: " to every line received as many lines can be sent in a single chunk. However the opposite might happen too, i.e. a single message line split amongst multiple chunks. This patch adds support for the later case to avoid displays like: remote: Compressing objeremote: cts: 100% (313/313), done. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* recv_sideband: Do not use ANSI escape sequence on dumb terminals.Johannes Sixt2008-01-09
| | | | | | | | | | | | | | | | The "clear to end of line" sequence is used to nicely output the progress indicator without leaving garbage on the terminal. However, this works only on ANSI capable terminals. We use the same check as in color.c to find out whether the terminal supports this feature and use a workaround (a few spaces in a row) if it does not. [jc: as an old fashoned git myself, and given the fact that the possible prefix and suffix are small number of short constant strings, I actually prefer a simpler-and-more-stupid approach. This is with Nico's clean-up.] Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sideband.c: ESC is spelled '\033' not '\e' for portability.Nicolas Pitre2007-11-05
| | | | | Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fix display overlap between remote and local progressNicolas Pitre2007-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible for the remote summary line to be displayed over the local progress display line, and therefore that local progress gets bumped to the next line. However, if the progress line is long enough, it might not be entirely overwritten by the remote summary line. This creates a messed up display such as: remote: Total 310 (delta 160), reused 178 (delta 112)iB/s Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done. So we have to clear the screen line before displaying the remote message to make sure the local progress is not visible anymore on the first line. Yet some Git versions on the remote side might be sending updates to the same line and terminate it with \r, and a separate packet with a single \n might be sent later when the progress display is done. This means the screen line must *not* be cleared in that case. Since the sideband code already has to figure out line breaks in the received packet to properly prepend the "remote:" prefix, we can easily determine if the remote line about to be displayed is empty. Only when it is not then a proper suffix is inserted before the \r or \n to clear the end of the screen line. Also some magic constants related to the prefix length have been replaced with a variable, making it similar to the suffix length handling. Since gcc is smart enough to detect that the variable is constant there is no impact on the generated code. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cope with multiple line breaks within sideband progress messagesNicolas Pitre2007-10-17
| | | | | | | | | | A single sideband packet may sometimes contain multiple lines of progress messages, but we prepend "remote: " only to the whole buffer which creates a messed up display in that case. Make sure that the "remote: " prefix is applied to every remote lines. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* atomic write for sideband remote messagesNicolas Pitre2006-10-11
| | | | | | | | | | | | | | | | | | | | | It has been a few times that I ended up with such a confusing display: |remote: Generating pack... |remote: Done counting 17 objects. |remote: Result has 9 objects. |remote: Deltifying 9 objects. |remote: 100% (9/9) done |remote: Unpacking 9 objects |Total 9, written 9 (delta 8), reused 0 (delta 0) | 100% (9/9) done The confusion can be avoided in most cases by writing the remote message in one go to prevent interleacing with local messages. The buffer declaration has been moved inside recv_sideband() to avoid extra string copies. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Move sideband server side support into reusable form.Junio C Hamano2006-09-10
| | | | | | | | The server side support; this is just the very low level, and the caller needs to know which band it wants to send things out. Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from b786552b67878c7780c50def4c069d46dc54efbe commit)
* Move sideband client side support into reusable form.Junio C Hamano2006-09-10
This moves the receiver side of the sideband support from fetch-clone.c to sideband.c and its header file, so that archiver protocol can use it. Signed-off-by: Junio C Hamano <junkio@cox.net>