git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/3] Allow help.htmlpath to be an http: URL

From
Jeff King <peff@peff.net>
Date
Jun 27, 2012, 22:52 UTC
Message-ID
<20120627225248.GB27566@sigill.intra.peff.net>
In-Reply-To
<20120627221938.GA1742@arachsys.com>
On Wed, Jun 27, 2012 at 11:19:39PM +0100, Chris Webb wrote:
Show 11 quoted lines
> Jeff King <peff@peff.net> 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
Previous: Chris WebbNext: Junio C Hamano
Message 10 of 15 in “A handful of help-related patches”
  1. Chris WebbJun 27, 2012
  2. 1/3 Add config variable to set HTML path for git-help --webChris Webb, Jun 27, 2012
  3. 2/3 Allow help.htmlpath to be an http: URLChris Webb, Jun 27, 2012
  4. Jeff KingJun 27, 2012
  5. Chris WebbJun 27, 2012
  6. Junio C HamanoJun 27, 2012
  7. Chris WebbJun 27, 2012
  8. Jeff KingJun 27, 2012
  9. Chris WebbJun 27, 2012
  10. Jeff KingJun 27, 2012
  11. Junio C HamanoJun 28, 2012
  12. Chris WebbJun 28, 2012
  13. Jeff KingJun 28, 2012
  14. Chris WebbJun 28, 2012
  15. 3/3 Add a help format 'usage' to provide brief command usageChris Webb, Jun 27, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.