Граф коммитов

4 Коммитов

Автор SHA1 Сообщение Дата
Nicolas Pitre ed1902ef5c cope with multiple line breaks within sideband progress messages
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>
2007-10-17 02:54:56 -04:00
Nicolas Pitre 9ac13ec941 atomic write for sideband remote messages
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>
2006-10-11 11:13:01 -07:00
Junio C Hamano 958c24b1b8 Move sideband server side support into reusable form.
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)
2006-09-10 13:36:50 -07:00
Junio C Hamano 49a52b1d1f Move sideband client side support into reusable form.
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>
2006-09-10 13:36:35 -07:00