git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Aghiles <aghilesk@gmail.com>
Cc: git list <git@vger.kernel.org>
Subject: Re: Useless error message?
Date: Wed, 21 Apr 2010 17:19:54 -0500	[thread overview]
Message-ID: <20100421221953.GA25348@progeny.tock> (raw)
In-Reply-To: <z2o3abd05a91004211417v263d5a0eg497341ddf7bd79a5@mail.gmail.com>

Aghiles wrote:

> "fatal: The remote end hung up unexpectedly"
> 
> Is that really meaningful ? Or maybe it is a configuration problem
> on my side ?

Please, fix it. :)

The problem is this: as far as I can tell, the git protocols are
designed around the success case.  Sometimes if there is an error or
other interesting event, the servers are kind enough to notify the
user “on the side”.  But in the end, all too often, they do not bother
to inform the client _program_ that a fatal error occured.

We can’t just throw away this hang-up message because sometimes when
the remote host hangs up it really was unexpected.

So the trick is to make it expected more often.  See the side-band-64k
capability in Documentation/technical/protocol-capabilities.txt: the
goal is to have fatal error messages for as many failure modes as
possible.

Examples (I could be missing nuances; I am just trying to convey
the idea):

upload-archive:
 - a pipe(), write(), or poll() failure when communicating over
   the wire or between local processes will result in an unexpected
   hangup.  I have not checked, but I suspect a SIGPIPE can kill
   upload-archive, too.
 - On the bright side, all other error conditions are properly
   handled.  The code for this is very nice and worth imitating.

upload-pack:
 - a missing or shallow repo, HEAD or some other ref pointing to
   a nonexistent object, early protocol error, or failure to start
   rev-list or pack-objects will result in an unexpected hangup.
 - errors from rev-list, pack-objects, or the transition of the
   generated pack are correctly handled.

receive-pack:
 - all errors result in unexpected hup as far as I can tell.

daemon:
 - hangs up without an explanation (except to syslog) for invalid
   or disabled repositories
 - if the underlying service hangs up, hangs up.  If the underlying
   service writes a message to stderr, writes that message to
   syslog.  Surely the client is not interested...

If any other information would help, please let me know.
Jonathan

  parent reply	other threads:[~2010-04-21 22:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 21:17 Useless error message? Aghiles
2010-04-21 21:29 ` Kim Ebert
2010-04-21 22:19 ` Jonathan Nieder [this message]
2010-04-22  6:33   ` Junio C Hamano
2010-04-22  9:42     ` Jonathan Nieder
2010-04-22  9:59       ` Andreas Ericsson
2010-04-22 10:15         ` Jonathan Nieder
2010-04-22 10:27           ` Andreas Ericsson
2010-04-22 10:38             ` Jonathan Nieder
2010-04-22 12:44       ` Ilari Liusvaara
2010-04-22 22:21         ` [PATCH] daemon: report inaccessible repositories to user Jonathan Nieder
2010-04-22 11:56   ` Useless error message? Petr Baudis
2010-04-22 20:13     ` Aghiles

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100421221953.GA25348@progeny.tock \
    --to=jrnieder@gmail.com \
    --cc=aghilesk@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).