Jonathan Nieder <jrnieder@gmail.com> writes:

quoted text
> 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.

The true story is a bit different.

To avoid information leak to git-daemon clients, we deliberately choose
not to give detailed error messages, so that you cannot tell if an error
means a user "u" does not exist or "u" does but ~u/repo.git repository
does not exist.

quoted text
> 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.

For authenticated users (read: services that typically are behind auth) it
would be a good thing, but "as many as possible" you shouldn't be followed
blindly.
--
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