git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Sergei Organov <osv@javad.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] Let git-help prefer man-pages installed with this version of git
Date: Fri, 07 Dec 2007 02:39:24 -0800	[thread overview]
Message-ID: <7vodd23i1v.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <87d4ti7qu1.fsf@osv.gnss.ru> (Sergei Organov's message of "Fri, 07 Dec 2007 13:16:06 +0300")

Sergei Organov <osv@javad.com> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Thu, 6 Dec 2007, Sergei Organov wrote:
>>
>>> Prepend $(prefix)/share/man to the MANPATH environment variable before 
>>> invoking 'man' from help.c:show_man_page().
>>
>> This commit message is severely lacking.  Why would you _ever_ prefer the 
>> installed man pages before invoking "man", which should find them
>> anyway?
>
> Obviously because you want manual pages corresponding to the version of
> git you are invoking, not any random version of man-pages man may find
> by default.

While I almost agree with the rest of your sentence, you have to realize
that it is obviously not obvious if somebody asked you to clarify.

How about this:

    Prepend $(prefix)/share/man to the MANPATH environment variable
    before invoking 'man' from help.c:show_man_page().  There may be
    other git documentation in the user's MANPATH but the user is asking
    a specific instance of git about its own documentation, so we'd
    better show the documentation for _that_ instance of git.

Having written that, it is very tempting to further clarify the above:

    Usually, if a user has his own version of git and regularly uses it
    by having the non-system executable directory (e.g. $HOME/bin/git)
    early in his $PATH, its corresponding documentation would also be in
    a non-system documentation directory (e.g. $HOME/man) early in his
    $MANPATH, and this change is a no-op.  The only case this change
    matters is where the user installs his own git outside of his $PATH
    and $MANPATH, and explicitly runs his git executable
    (e.g. "$HOME/junk/git-1.5.4/bin/git diff").

When you clarify it this way, the change does not look as useful
anymore, does it?  How typical would that use be, to run your git
executable by always naming it by path without relying on $PATH
environment variable?

  reply	other threads:[~2007-12-07 10:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06 18:33 [PATCH] Let git-help prefer man-pages installed with this version of git Sergei Organov
2007-12-06 20:09 ` Johannes Schindelin
2007-12-07 10:16   ` Sergei Organov
2007-12-07 10:39     ` Junio C Hamano [this message]
2007-12-07 11:51       ` Sergei Organov
2007-12-07 12:38         ` Andreas Ericsson
2007-12-07 12:49           ` Sergei Organov
2007-12-07 19:29         ` Junio C Hamano
2007-12-07 16:19       ` David Brown
2007-12-07 16:22         ` David Brown

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=7vodd23i1v.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=osv@javad.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).