Re: git quietly fails on https:// URL, https errors are never reported to user

Yuri <yuri@rawbw.com> writes:

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 ;-)