Yuri <yuri@xxxxxxxxx> writes:
> I think that in a rare case of error this extra-printout wouldn't
> hurt.
If the "error is rare, extra verbiage does not hurt" were a valid
attitude, "error is rare, non-zero exit is enough" would be equally
valid ;-)
Also that statement contradicts with the rationale given by 266f1fdf
(transport-helper: be quiet on read errors from helpers,
2013-06-21), no?
However, this makes a much more common case worse: when a helper
does die with a useful message, we print the extra "Reading from
'git-remote-foo failed" message. This can also end up confusing
users, as they may not even know what remote helpers are (e.g.,
the fact that http support comes through git-remote-https is
purely an implementation detail that most users do not know or
care about).
Your change is not an exact revert and rewords the message to read
Failure in 'http' protocol reader.
instead of
Reading from helper 'git-remote-http' failed.
which avoids the "helper" word and replacing it with "protocol
reader" [*1*] in an attempt to make it less likely to "end up
confusing users", but I am not sure if "protocol reader" is good
enough for those who get confused with "helper" in the first place.
They will ask their resident guru or favourite search engine about
the message and will be told that your http connection did not go
well either way, but not many people have seen this new message.
If we were to reinstate the extra final line in the error message, I
think we would be off doing a straight revert without any rewording
that introduces yet another word "protocol reader" that is not found
anywhere in our glossary.
I think I am OK with adding one more line after "Reading from
... failed" that explains a more detailed error message might be
there above that line, but I am not sure what the good phrasing
would be.
[Footnote]
*1* It may introduce a new confusion "was it 'read' that failed, or
'write'?", though ;-)
--
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