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

[Jeff King <peff@peff.net>]

On Fri, Jan 17, 2014 at 12:39:39PM -0800, Yuri wrote:

> >That second line is not adding anything, and IMHO is making things
> >uglier and more confusing. We_expected_  the helper to hang up; that's
> >how it signals an error to us. It is not an unexpected condition at all.
> >The exit(128) we do is simply propagating the error report of the
> >helper.
> >
> >That's the common error case: the message is redundant and annoying. The
> >_uncommon_  case is the one Yuri hit: some library misconfiguration that
> >causes the helper not to run at all.  Adding back any message is hurting
> >the common case to help the uncommon one.
> 
> But you can use the error code value to convey the cause of the
> failure to git, and avoid an unnecessary message in git itself. Based
> on the error code value git could tell if the error has already been
> reported to user.

Yes, we can, but that is in the same boat as a protocol change: you have
to teach every remote helper (some of which are written by third
parties) to communicate over this sideband channel.

It's should be slightly easier than a change to the protocol text,
because it's mostly backwards compatible (helpers should already be
returning a non-zero error code). I think there is some complication
with exit codes and remote-helpers, where you cannot expect just check
the exit code at any time. I _think_ from previous discussions that it
is safe to waitpid() on the helper after we have gotten EOF on the
reading pipe, though.

-Peff