Re: [PATCH v2] help: make option --help open man pages only for Git commands

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 15, 2016, 17:57 UTC
Message-ID: <xmqqr39phq3c.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <D954CB3E6C3445AF9358C6941362B69D@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 10 quoted lines

> I'm still not sure this is enough. One of the problems back when I
> introduced the --guides option (65f9835 (builtin/help.c: add --guide
> option, 2013-04-02)) was that we had no easy way of determining what
> guides were available, especially given the *nix/Windows split where
> the help defaults are different (--man/--html).
>
> At the time[1] we (I) punted on trying to determine which guides were
> actually installed, and just created a short list of the important
> guides, which I believe you now check. However the less common guides
> are still there (gitcvs-migration?), and others may be added locally.

I think we should do both; "git help cvs-migration" should keep the same codeflow and behaviour as we have today (so that it would still work), while "git cvs-migration --help" should say "'cvs-migration' is not a git command". That would be a good clean-up anyway.

It obviously cannot be done if git.c::handle_builtin() does the same "swap <word> --help to help <word>" hack, but we could improve that part (e.g. rewrite it to "help --swapped <word>" to allow cmd_help() to notice). When the user said "<word> --help", we don't do guides, when we swapped the word order, we check with guides, too.