From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
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 14:32:49 -0700 [thread overview]
Message-ID: <7vbok4785a.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120627210502.GB2292@sigill.intra.peff.net> (Jeff King's message of "Wed, 27 Jun 2012 17:05:02 -0400")
Jeff King <peff@peff•net> writes:
> On Wed, Jun 27, 2012 at 09:55:13PM +0100, Chris Webb wrote:
>
>> Setting this to a URL prefix instead of a path to a local directory allows
>> git-help --web to work even when HTML docs aren't locally installed, by
>> pointing the browser at a copy accessible on the web. For example,
>>
>> [help]
>> format = html
>> htmlpath = http://git-scm.com/docs
>>
>> will use the publicly available documentation on the git homepage.
>
> Nice.
>
>> /* 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?"
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?"
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.
It also is the simplest.
next prev parent reply other threads:[~2012-06-27 21:32 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 [this message]
2012-06-27 21:41 ` Chris Webb
2012-06-27 22:11 ` Jeff King
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=7vbok4785a.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=chris@arachsys$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox