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