Re: [BUG] clone: regression in error messages in master

[Jeff King <peff@peff.net>]

On Thu, Jun 20, 2013 at 06:46:55PM +0530, Ramkumar Ramachandra wrote:

> So this should explain the problem:
> 
>   # using v1.8.3.1
>   $ git clone https://google.com
>   Cloning into 'google.com'...
>   fatal: repository 'https://google.com/' not found
> 
>   # using master
>   $ git clone https://google.com
>   Cloning into 'google.com'...
>   fatal: repository 'https://google.com/' not found
>   fatal: Reading from helper 'git-remote-https' failed
>
> [...]
> The bisect pointed me to: 81d340d4 (transport-helper: report errors
> properly, 2013-04-10).

Yeah, that is a not-so-great fallout from 81d340d4. The point of that
commit was that we do not know whether the remote helper has printed
anything useful; it died unexpectedly while we tried to read from it.

In this case, of course it has, and so the extra message is redundant
and unwanted.

I'm not sure if there is a good way to distinguish the two cases
(snooping on stderr would add complexity, and is not even robust, as we
do not know the meaning of human-readable messages coming over stderr).
Waiting for an "expected" time for the helper give us EOF does not work
either; I think in this case we asked for a "list" or "fetch", and the
helper died without giving us an answer (because there is no answer to
give; there is no "oops, I could not complete your request" on the
fetch side of the transport helper protocol).

So I'm not sure if there is a better option than reverting 81d340d4 and
living with the lesser of two evils (no good message when the helper
dies silently).

-Peff