Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html