All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Chris Webb <chris@arachsys.com>, git@vger.kernel.org
Subject: Re: [PATCH 2/3] Allow help.htmlpath to be an http: URL
Date: Wed, 27 Jun 2012 18:11:07 -0400	[thread overview]
Message-ID: <20120627221106.GE2292@sigill.intra.peff.net> (raw)
In-Reply-To: <7vbok4785a.fsf@alter.siamese.dyndns.org>

On Wed, Jun 27, 2012 at 02:32:49PM -0700, Junio C Hamano wrote:

> >>  	/* Check that we have a git documentation directory. */
> >> -	if (stat(mkpath("%s/git.html", html_path), &st)
> >> -	    || !S_ISREG(st.st_mode))
> >> -		die(_("'%s': not a documentation directory."), html_path);
> >> +	if (prefixcmp(html_path, "http:")) {
> >> +		if (stat(mkpath("%s/git.html", html_path), &st)
> >> +				|| !S_ISREG(st.st_mode))
> >> +			die("'%s': not a documentation directory.", html_path);
> >> +	}
> >
> > I'd rather not tie this directly to http. Is there any reason not to
> > allow https, for example? Can we maybe just look for strstr("://")
> > instead? That's the same magic we use to differentiate URLs from paths
> > when looking for repositories.
> 
> One part of me says "any non-standard html-path should be sent to
> the browser".  Another part of me says "what if network is
> unavailable?  Wouldn't it be nice to fall back to use the local
> copy?"

Fallback might be nice, but I really don't want to get into interpreting
what URLs mean or whether the network is up.

> And a small voice in me responds to the latter with "If you have a
> local copy anyway, why would you want to go to the network even if
> you could?"

One reason is that the network version may contain more information (for
example, the git-scm.com versions give you links to related articles,
and also tell you in which versions the documentation changed).

Speaking of versions, this patch is not sufficient to actually point the
browser to the correct version at a site like git-scm.com. We could add
some kind of strbuf_expand magic like "http://git-scm.com/%c/%v" or
something like that (where %c is the command and %v is the git version).
But that is probably over-engineering.

> Which leads me to conclude that it is the right thing to do if
> html_path came from the configuration, not from the compiled-in
> default, to always ask browser to do its thing, and let it fail if
> it has to fail---it is not Git's problem anymore at that point.

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.

-Peff

  parent reply	other threads:[~2012-06-27 22:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 20:54 A handful of help-related patches Chris Webb
2012-06-27 20:55 ` [PATCH 1/3] Add config variable to set HTML path for git-help --web Chris Webb
2012-06-27 20:55   ` [PATCH 2/3] Allow help.htmlpath to be an http: URL Chris Webb
2012-06-27 21:05     ` Jeff King
2012-06-27 21:12       ` Chris Webb
2012-06-27 21:32       ` Junio C Hamano
2012-06-27 21:41         ` Chris Webb
2012-06-27 22:11         ` Jeff King [this message]
2012-06-27 22:19           ` Chris Webb
2012-06-27 22:52             ` Jeff King
2012-06-28  2:41               ` Junio C Hamano
2012-06-28  6:56               ` Chris Webb
2012-06-28 17:50                 ` Jeff King
2012-06-28 23:39                   ` Chris Webb
2012-06-27 20:55   ` [PATCH 3/3] Add a help format 'usage' to provide brief command usage Chris Webb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120627221106.GE2292@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=chris@arachsys.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.