On Wed, Jun 27, 2012 at 11:19:39PM +0100, Chris Webb wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I don't know that configured vs compiled-in is the right distinction > > there, though. If I'm building a minimal git for a stripped-down machine > > and I don't want to include the HTML pages locally, I might want to set > > the html path to a URL at build-time. That saves each user from having > > to configure it. > > How about only testing for a git documentation directory if both > help.htmlpath isn't set (so we're using the compiled-in version) and the > compiled-in version doesn't contain ://? That just seems needlessly complex. Why not just check for "://" and be done? Let's take a step back for a moment. Why is that check even there? You can always just hand the path (or URL, or whatever) to the browser command and hope it can make sense of it. If it can't, it will give you an error. I think the check is purely about being slightly nicer when there are no HTML docs at all (e.g., because you didn't bother building them, or your binary distribution didn't include them). If your browser is graphical, we'll spawn it with a bogus URL, and the error message will be in some window elsewhere on your desktop. Git will happily exit without a further message. By adding in that check, we can detect that situation and produce an error message immediately. So one solution would be to simply remove the check entirely. It was a slight nicety in some situations, but expanding the definition of the HTML path to include full URLs means we can no longer accurately determine what exists and what does not. So we can just stop trying and let the browser handle it completely. Another option would be to introduce a new "net" type of help format which accepts a URL instead of a path. That would leave the existing code-path untouched. But it does seem needlessly complex, as it would do more or less the same thing as the "html" format. -Peff -- 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