Useless error message?
From: Aghiles <hidden>
Date: 2016-06-15 22:48:41
"fatal: The remote end hung up unexpectedly" Is that really meaningful ? Or maybe it is a configuration problem on my side ? -- aghiles
5 messages, 4 authors, 2016-06-15 · open the first message on its own page
From: Aghiles <hidden>
Date: 2016-06-15 22:48:41
"fatal: The remote end hung up unexpectedly" Is that really meaningful ? Or maybe it is a configuration problem on my side ? -- aghiles
From: Kim Ebert <hidden>
Date: 2016-06-15 22:48:41
I find that it usually means I didn't set up git-daemon-export-ok. Of course, that has usually been my experience. Aghiles wrote:
"fatal: The remote end hung up unexpectedly" Is that really meaningful ? Or maybe it is a configuration problem on my side ? -- aghiles -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:48:41
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
From: Petr Baudis <hidden>
Date: 2016-06-15 22:48:41
On Wed, Apr 21, 2010 at 05:19:54PM -0500, Jonathan Nieder wrote:
Aghiles wrote:quoted
"fatal: The remote end hung up unexpectedly" Is that really meaningful ? Or maybe it is a configuration problem on my side ?Please, fix it. :)
I have seen a lot of users who plainly had a lot of trouble even _understanding_ the error message - it is phrased in super-dense networking jargon. I think something like "fatal: Server terminated the connection for unknown reason" might come a long way (though of course specific error messages would still be far more helpful). (I assume that the remote end is the server since (i) it is most often the case (ii) it is if you look at it through the client-server optics, which may not always be the best one, but see (i).) -- Petr "Pasky" Baudis http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
From: Aghiles <hidden>
Date: 2016-06-15 22:48:41
Hello,
I have seen a lot of users who plainly had a lot of trouble even _understanding_ the error message - it is phrased in super-dense networking jargon. I think something like "fatal: Server terminated the connection for unknown reason" might come a long way (though of course specific error messages would still be far more helpful).
I would say that: "fatal: Server terminated the connection." Is best and actually says what it has to stay. "Unknown reason" sounds like a godly intervention into the git protocol. Sometimes, the "hung up" message is given as an extra information that actually causes more harm than good: % git pull hummus fatal: 'hummus' does not appear to be a git repository fatal: The remote end hung up unexpectedly -- aghiles