Re: [PATCH v4] Refactor recv_sideband()

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 28, 2016, 19:51 UTC
Message-ID: <xmqq60st853d.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.LFD.2.20.1606281422500.24439@knanqh.ubzr>

Nicolas Pitre <nico@fluxnic.net> writes:

Show 7 quoted lines

> Without this, the error and remaining buffer would be reversed as 
> mentioned previously.  With this, the order is restored, but a newline 
> is added to unterminated lines whereas the error was simply appended to 
> the output before Lukas' patch.
>
> In any case the new behavior is probably better and I'd simply adjust 
> the test expectations.

There is something else going on. I cannot quite explain why I am getting this failure from t5401-update-hooks.sh, for example:

    --- expect      2016-06-28 19:46:24.564937075 +0000
    +++ actual      2016-06-28 19:46:24.564937075 +0000
    @@ -9,3 +9,4 @@
     remote: STDERR post-receive
     remote: STDOUT post-update
     remote: STDERR post-update
    +remote: To ./victim.git
    not ok 12 - send-pack stderr contains hook messages

... goes and looks what v2.9.0 produces, which ends like this:

    ...
    remote: STDERR post-receive        
    remote: STDOUT post-update        
    remote: STDERR post-update        
    To ./victim.git
       e4822ab..2b65bd1  master -> master
     ! [remote rejected] tofail -> tofail (hook declined)

The test checks if lines prefixed with "remote: " match the expected output, and the difference is an indication that the new code is showing an extra incomplete-line "remote: " before other parts of the code says "To ./victim.git" to report where the push is going.

It appeasrs that the "Refector"ed logic needs to be a bit more careful when relaying an empty payload.