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