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.
Signed-off-by: Marcus Griep <marcus@griep.us>

---
 By adding them to the help completion, man pages such as the tutorials, hooks,

 and .gitattributes are more accessible to random discovery from bash-completion.
 contrib/completion/git-completion.bash |    6 +++++-

 1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash

index c0bf7aa..76d56eb 100755

--- a/contrib/completion/git-completion.bash

+++ b/contrib/completion/git-completion.bash

@@ -885,7 +885,11 @@ _git_help ()

 		return

 		;;

 	esac

-	__gitcomp "$(__git_all_commands)"

+	__gitcomp "$(__git_all_commands)

+		attributes cli core-tutorial cvs-migration

+		diffcore glossary hooks ignore k modules

+		repository-layout tutorial tutorial-2

+		"

 }
 _git_init ()

--

1.6.0.rc2.6.g8eda3
--

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 through bash-completion without

the patch.
--

Marcus Griep

GPG Key ID: 0x5E968152

——

http://www.boohaunt.net

את.ψο´

--

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.
--

How about something simple like this?
diff --git a/builtin-help.c b/builtin-help.c

index 391f749..a49b5c2 100644

--- a/builtin-help.c

+++ b/builtin-help.c

@@ -446,6 +446,11 @@ int cmd_help(int argc, const char **argv, const

char *prefix)

                 return 0;

         }
+       if (!strcmp("man-path", argv[0])) {

+               printf("%s\n", GIT_MAN_PATH);

+               return 0;

+       }

+

         switch (help_format) {

         case HELP_FORMAT_MAN:

                 show_man_page(argv[0]);

diff --git a/contrib/completion/git-completion.bash b/contrib/

completion/git-completion.bash

index 3396e35..f781661 100755

--- a/contrib/completion/git-completion.bash

+++ b/contrib/completion/git-completion.bash

@@ -885,7 +885,8 @@ _git_help ()

                 return

                 ;;

         esac

-       __gitcomp "$(__git_all_commands)"

+       __gitcomp "$(ls $(./git help man-path)/man?/* |

+         sed -n 's/^.*\/git-\{0,1\}\(.*\)\.[0-9]$/\1/p')"

  }
--

Are you working on next? Even though I know next is the new

master. (master is soooo nearly last week. :-P)
I had a slightly different take.  Your completion creates a 'k'

for gitk, which was suggested earlier in the thread suggested

is a bit harder to grok.  This promotes 'git?' commands to use

'git?' rather than '?' without affecting things otherwise.

---

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash

index c0bf7aa..0bb0d79 100755

--- a/contrib/completion/git-completion.bash

+++ b/contrib/completion/git-completion.bash

@@ -885,7 +885,9 @@ _git_help ()

                return

                ;;

        esac

-       __gitcomp "$(__git_all_commands)"

+       __gitcomp "$(ls $(./git help man-path)/man?/* |

+               sed -n -e 's/^.*\/git-\?\(.\{2,\}\)\.[0-9]$/\1/p' \

+                       -e 's/^.*\/git\(.\)\.[0-9]$/git\1/p')"

 }
 _git_init ()

diff --git a/help.c b/help.c

index 3cb1962..d0416e1 100644

--- a/help.c

+++ b/help.c

@@ -717,6 +717,11 @@ int cmd_help(int argc, const char **argv, const char *prefix)

                return 0;

        }
+       if (!strcmp("man-path", argv[0])) {

+               printf("%s\n", GIT_MAN_PATH);

+               return 0;

+       }

+

        switch (help_format) {

        case HELP_FORMAT_MAN:

                show_man_page(argv[0]);

---
What do you think, Junio?  If it works, I'll make this a

normal patch submission.
--

Marcus Griep

GPG Key ID: 0x5E968152

——

http://www.boohaunt.net

את.ψο´

--

Gotcha.  A static list buried in git-completion.bash would be a maintenance

headache.  I can take a look at that some.
Would we also want to look at doing something similar with '--' option

completion, i.e. invoking the command with '-h' to get the usage and long

options, then building the completion list on that rather than the static

lists it uses now?  The one downside to that is that some completions

include trailing '=', which wouldn't be present in a usage list.
--

Marcus Griep

GPG Key ID: 0x5E968152

——

http://www.boohaunt.net

את.ψο´

--

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.
Signed-off-by: Marcus Griep <marcus@griep.us>

---
 By adding them to the help completion, man pages such as the tutorials, hooks,

 and .gitattributes are more accessible to random discovery from bash-completion.
 This patch also incorporates the suggestion that 'gitk' is an easier to grok

 completion than 'k'.
 contrib/completion/git-completion.bash |    6 +++++-

 1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash

index c0bf7aa..158b912 100755

--- a/contrib/completion/git-completion.bash

+++ b/contrib/completion/git-completion.bash

@@ -885,7 +885,11 @@ _git_help ()

 		return

 		;;

 	esac

-	__gitcomp "$(__git_all_commands)"

+	__gitcomp "$(__git_all_commands)

+		attributes cli core-tutorial cvs-migration

+		diffcore gitk glossary hooks ignore modules

+		repository-layout tutorial tutorial-2

+		"

 }
 _git_init ()

--

1.6.0.rc3.10.g5a13c
--

--

Shawn.

--

I'd honor this Ack for 1.6.0 and will apply the patch as-is, but that does

not mean I do not think this is a wrong approach in the longer run.

--

Hi,
I think k should be gitk here :)
Regards,

Jonathan

--

It can be either.  In a bash-completion list, though, gitk would probably

be more recognizable.  I'll rehash that one.
--

Marcus Griep

GPG Key ID: 0x5E968152

——

http://www.boohaunt.net

את.ψο´

--