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

From: Jeff King <peff@peff.net>
Date: Jan 17, 2014, 21:10 UTC
Message-ID: <20140117211035.GA8447@sigill.intra.peff.net>
In-Reply-To: <52D9950B.3030300@rawbw.com>

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

Show 15 quoted lines

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