Sverre Rabbelier wrote:
> I noticed this when my tests suddenly broke. Bisecting pointed at
> the 'more rigorous return value checking' patch
Shouldn't this go before "check status code of finish_command" for
bisectability, then?
> I'm not very sure about the error message, if anyone feels it
> should go (it indicates a bug in the remote helper infrastructure,
> not a user error) it can be left out as far as I'm concerned.
No preference here.
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -813,6 +813,8 @@ int main(int argc, const char **argv)
> do {
> if (strbuf_getline(&buf, stdin, '\n') == EOF)
> break;
> + if (buf.len == 0)
> + break;
This is just a bug, I think. Other strbuf_getline() invocations in
that file all use the equivalent
if (*buf->buf)
break;
too.
> @@ -851,6 +853,7 @@ int main(int argc, const char **argv)
> printf("\n");
> fflush(stdout);
> } else {
> + fprintf(stderr, "Unknown command '%s'\n", buf.buf);
> return 1;
> }
Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
--
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