Nicolas Pitre <nico@xxxxxxxxxxx> writes:
> 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.
--
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