Jeff King wrote: > I'm tempted to suggest this on top: > > -- >8 -- > Subject: [PATCH] daemon: turn on informative errors by default Very good idea, as long as we are cautious about making sure admins know about the change before it comes (for example using release notes). [...] > Git is foremost an open system, and our defaults should > reflect that. I think this is a lousy justification. :) Sure, certain prominent users of git (like kernel.org) would probably not want to set --no-informative-errors. And you and I might prefer that _nobody_ set --no-informative-errors. But this does not mean the design of Git has anything to do with that, and I am afraid of the direction it would take us in if we start pretending it does. The git daemon is primarily a functional, secure, admin-friendly and client-friendly program whose defaults should make admins happy where possible. Luckily all that is consistent with --informative-errors. In most use cases (i.e., not weird military security kinds of things), although --informative-errors without --base-path could have negative security impact as Andreas has explained before, --informative-errors with --base-path is harmless as far as I can tell. I am tempted to propose making --base-path mandatory when there is not at least one path_ok argument, so in the unusual case, people would have to explicitly say they want to serve repositories rooted at /. Just my two cents, Jonathan -- 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