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
> >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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html