From: Junio C Hamano <gitster@pobox.com>
To: Marcus Griep <marcus@griep.us>
Cc: Git Mailing List <git@vger.kernel.org>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH] bash-completion: Add non-command git help files to bash-completion
Date: Fri, 15 Aug 2008 11:50:51 -0700 [thread overview]
Message-ID: <7vvdy29kok.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <48A5CC07.2040500@griep.us> (Marcus Griep's message of "Fri, 15 Aug 2008 14:33:43 -0400")
Marcus Griep <marcus@griep.us> writes:
> Junio C Hamano wrote:
>> Marcus Griep <marcus@griep.us> writes:
>>
>>> Git allows access to the gitattributes man page via `git help attributes`,
>>> but this is not discoverable via the bash-completion mechanism. This
>>> patch adds all current non-command man pages to the completion candidate
>>> list.
>>
>> I really do not think this belongs to completion. "git help topics"
>> perhaps.
>
> I'm not sure I grok what you mean here... These items are already accessible
> from `git help`, they just aren't discoverable...
That is exactly what I mean. I do not think bloating shell completion to
enumerate what help topics there are when the user hits "git help <TAB>"
is a good idea to begin with. It is a maintenance nightmere for one
thing, and it does not help non-bash users.
$ git help
$ git help --all
are existing ways for you to get list of "command topics" that you can ask
the help system about, but I do not see a way to ask "git-help, please
tell me what topics that are not git-commands can I ask you about?", hence
my suggestion to add "git help topics".
And if you based "git help <TAB>" completion on the output from such help
subcommand, you would not have to maintain the list of topics yourself in
the completion script, and I would not mind such a patch too much.
next prev parent reply other threads:[~2008-08-15 18:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-15 16:15 [PATCH] bash-completion: Add non-command git help files to bash-completion Marcus Griep
2008-08-15 17:38 ` Jonathan Nieder
2008-08-15 17:53 ` Marcus Griep
2008-08-15 17:59 ` [PATCH v2] " Marcus Griep
2008-08-15 18:00 ` Shawn O. Pearce
2008-08-16 9:30 ` Junio C Hamano
2008-08-15 18:21 ` [PATCH] " Junio C Hamano
2008-08-15 18:33 ` Marcus Griep
2008-08-15 18:50 ` Junio C Hamano [this message]
2008-08-15 19:03 ` Marcus Griep
2008-08-15 20:32 ` Pieter de Bie
2008-08-15 21:17 ` Marcus Griep
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=7vvdy29kok.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=marcus@griep.us \
--cc=spearce@spearce.org \
/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.