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

On Wed, Jun 27, 2012 at 11:19:39PM +0100, Chris Webb wrote:

> 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

  reply	other threads:[~2012-06-27 22:53 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
2012-06-27 22:19           ` Chris Webb
2012-06-27 22:52             ` Jeff King [this message]
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=20120627225248.GB27566@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.