On Mon, May 18, 2020 at 03:52:42PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
So I think our options are probably:
1. detect flush packets in remote-curl, and either:
a. don't print an error, just hang up. That prevents a hang in the
caller and produces no extra message on a real error. It may be
less informative than it could be if the connection hangs up
(though we may print a curl error message, and the caller will
at least say "the helper hung up")
b. like (a), but always print an error; this is your original
patch, but I _suspect_ (but didn't test) that it would produce
extra useless messages for errors the server reports
c. between the two: inspect the final packet data for evidence of
ERR/sideband 3 and suppress any message if found
2. helper signals end-of-response to caller (then it never produces a
message itself; only the caller does, and it would abort on an ERR
packet before then)
a. using a special pktline (your "0002" patch)
b. some other out-of-band mechanism (e.g., could be another fd)
I think this is pushing me towards 2a, your "0002" patch. It sidesteps
the error-message questions entirely (and I think 2b is too convoluted
to be worth pursuing, especially on Windows where setting up extra pipes
is tricky). But I'd also be OK with 1a or 1c.
Thanks for a detailed analysis. I guess we'd take 0002, then?
Yeah, that's how I lean. I think I did have a few comments on the patch
that I'd like Denton to consider, so hopefully we'll see a re-roll.
-Peff