On Mon, 18 Dec 2006, Linus Torvalds wrote: > > Maybe we could provide a more clueful error message in that case... > > Well, for security reasons, the remote side really shouldn't talk about > _why_ a fetch failed. I do NOT like the idea of git-daemon returning > different errors for different failures, because then you can start using > it to do things like test whether a file exists (independently of any git > issues), by (for example) just doing > > git clone git.kernel.org/some/random/non/git/file > > and seeing whether you get an "directory does not exist" or "not a valid > git repo" or a "not a directory" error. > > So git-daemon - quite on purpose - will just silently close the connection > regardless of why an error happened (at least the early errors). Exactly > because it does NOT like the idea of having some attacker possibly poking > the server with invalid input and hoping to get information about > filesystem layout. I don't dispute that. It is just that "unexpected EOF" is a bit dry for the client's user who might not even know what EOF means. Nicolas - 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