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

[Jeff King <peff@peff.net>]

On Thu, Jan 16, 2014 at 04:27:03AM -0800, Yuri wrote:

> While debugging, I find that remove_junk() deletes all directories
> from under __cxa_finalize.
> Before this, exit(128) is called from recvline_fh ("Debug: Remote
> helper quit.) And this function in turn is called from under
> refs = transport_get_remote_refs(transport);
> 
> I think you need to make sure that any https errors (in this and
> other locations) are reported to the user, and git never quits on
> error without saying what the error is.

We used to print "Reading from helper 'git-remote-https' failed" in this
instance. But in the majority of cases, remote-https has printed a
useful message already to stderr, and the extra line just confused
people. The downside, as you noticed, is that when the helper dies
without printing an error, the user is left with no message.

Unfortunately, detecting whether the helper printed a useful message is
non-trivial. It's possible we could do more detection based on the
helper's death (e.g., if it died by signal, print a message) and at
least say _something_.

But even if we do so, the message isn't going to tell you what went
wrong, only that something unexpected happened.  It is up to the helper
to print something useful, and if it didn't, it should be fixed.  So the
most important bug to fix here, IMHO, is figuring out why
git-remote-https died without printing an error message.

Is it possible to strace (or truss) the helper process? What it was
doing when it died may be helpful. Rather than picking through "strace
-f" output, you can use this hack to trace just the helper process:

  cat >/in/your/$PATH/git-remote-strace <<\EOF
  #!/bin/sh
  protocol=$(echo "$2" | cut -d: -f1)
  exec strace git-remote-$protocol "$@"
  EOF

  git clone strace::https://github.com/your/repo.git

-Peff