Re: [PATCH v2] help: make option --help open man pages only for Git commands
- From
John Keeping <john@keeping.me.uk>
- Date
- Aug 16, 2016, 10:06 UTC
- Message-ID
- <20160816100633.be55qsbnlmlm37dr@john.keeping.me.uk>
- In-Reply-To
- <C8DDA334A45E4B558FD1EFB191E047C9@PhilipOakley>
On Mon, Aug 15, 2016 at 09:40:54PM +0100, Philip Oakley wrote:
Show 28 quoted lines
> From: "Junio C Hamano" <gitster@pobox.com> > > "Philip Oakley" <philipoakley@iee.org> writes: > > > >> 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. > > > The other option is to simply build a guide-list in exactly the same format > as the command list (which if it works can be merged later). Re-use the > existing code, etc.
One nice thing at the moment is that third-party Git commands can install documentation and have "git help" work correctly (shameless plug for git-integration[1] which does this). I think Junio's suggestion above keeps that working whereas having a hardcoded list of guides will break this.
[1] https://github.com/johnkeeping/git-integration