Junio C Hamano wrote: > 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. Thanks for the clarification. As I see it, these are two different classes of problem: 1. The git daemon is very quiet, usually for good reason, as you mentioned [1] [2]. 2. The git daemon and protocol helpers do not always send the datum “a controlled fatal error occured” by writing some message (any message) to side band 3. Fixing the daemon’s share in both might require setting up a side band very early. If an RFC patch appears setting up the side band (or an explanation for why that’s not possible), I would be happy to start work building from there. That has been the big obstacle for me experimenting with it, more than the information disclosure. But this is easy to say. The doing is more important. Thanks again, and sorry for the noise. Jonathan [1] I do suspect that in the case of failing enter_repo() or missing git-daemon-export-ok, saying “cannot read the specified repo” would be fine. Most of the time, there is not much value in disclosing a more detailed reason, anyway. [2] Example fix for a problem in this class: http://thread.gmane.org/gmane.comp.version-control.git/139029 -- 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