@matheusbsbs / matheus-bagliano / commits / 5210225f25

sideband: don't lose clear-to-eol at packet boundary

When "demultiplex_sideband()" sees a nonempty message ending with CR or LF on the sideband #2, it adds "suffix" string to clear to the end of the current line, which helps when relaying a progress display whose records are terminated with CRs. But if it sees a single LF, no clear-to-end suffix should be appended, because this single LF is used to end the progress display by moving to the next line, and the final progress display above should be preserved. However, the code forgot that depending on the length of the payload line, such a CR may fall exactly at the packet boundary and the number of bytes before the CR from the beginning of the packet could be zero. In such a case, the message that was terminated by the CR were leftover in the "scratch" buffer in the previous call to the function and we still need to clear to the end of the current line. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jiang Xin committed Jun 17, 2021 at 11:17 UTC 5210225f256d01938960d439bff9d809c2ff1809

1 file changed +23

sideband.c

+23

@@ -183,8 +183,31 @@ int demultiplex_sideband(const char *me, int status,

183 while ((brk = strpbrk(b, "\n\r"))) {

184 int linelen = brk - b;

185

186 + /*

187 + * For message accross packet boundary, there would have

188 + * a nonempty "scratch" buffer from last call of this

189 + * function, and there may have a leading CR/LF in "buf".

190 + * For this case we should add a clear-to-eol suffix to

191 + * clean leftover letters we previously have written on

192 + * the same line.

193 + */

194 + if (scratch->len && !linelen)

195 + strbuf_addstr(scratch, suffix);

196 +

197 if (!scratch->len)

198 strbuf_addstr(scratch, DISPLAY_PREFIX);

199 +

200 + /*

201 + * A use case that we should not add clear-to-eol suffix

202 + * to empty lines:

203 + *

204 + * For progress reporting we may receive a bunch of

205 + * percentage updates followed by '\r' to remain on the

206 + * same line, and at the end receive a single '\n' to

207 + * move to the next line. We should preserve the final

208 + * status report line by not appending clear-to-eol

209 + * suffix to this single line break.

210 + */

211 if (linelen > 0) {

212 maybe_colorize_sideband(scratch, b, linelen);

213 strbuf_addstr(scratch, suffix);