summaryrefslogtreecommitdiff
path: root/t/t0012-help.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-10-13Merge branch 'ab/help-config-vars'Libravatar Junio C Hamano1-0/+49
Teach "git help -c" into helping the command line completion of configuration variables. * ab/help-config-vars: help: move column config discovery to help.c library help / completion: make "git help" do the hard work help tests: test --config-for-completion option & output help: simplify by moving to OPT_CMDMODE() help: correct logic error in combining --all and --guides help: correct logic error in combining --all and --config help tests: add test for --config output help: correct usage & behavior of "git help --guides" help: correct the usage string in -h and documentation
2021-09-23help / completion: make "git help" do the hard workLibravatar Ævar Arnfjörð Bjarmason1-3/+14
The "help" builtin has been able to emit configuration variables since e17ca926371 (completion: drop the hard coded list of config vars, 2018-05-26), but it hasn't produced exactly the format the completion script wanted. Let's do that. We got partway there in 2675ea1cc0f (completion: use 'sort -u' to deduplicate config variable names, 2019-08-13) and d9438873c4d (completion: deduplicate configuration sections, 2019-08-13), but after both we still needed some sorting, de-duplicating and awk post-processing of the list. We can instead simply do the relevant parsing ourselves (we were doing most of it already), and call string_list_remove_duplicates() after already sorting the list, so the caller doesn't need to invoke "sort -u". The "--config-for-completion" output is the same as before after being passed through "sort -u". Then add a new "--config-sections-for-completion" option. Under that output we'll emit config sections like "alias" (instead of "alias." in the --config-for-completion output). We need to be careful to leave the "--config-for-completion" option compatible with users git, but are still running a shell with an older git-completion.bash. If we e.g. changed the option name they'd see messages about git-completion.bash being unable to find the "--config-for-completion" option. Such backwards compatibility isn't something we should bend over backwards for, it's only helping users who: * Upgrade git * Are in an old shell * The git-completion.bash in that shell hasn't cached the old "--config-for-completion" output already. But since it's easy in this case to retain compatibility, let's do it, the older versions of git-completion.bash won't care that the input they get doesn't change after a "sort -u". While we're at it let's make "--config-for-completion" die if there's anything left over in "argc", and do the same in the new "--config-sections-for-completion" option. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23help tests: test --config-for-completion option & outputLibravatar Ævar Arnfjörð Bjarmason1-1/+16
Add a regression test for the --config-for-completion option, this was tested for indirectly with the test added in 7a09a8f093e (completion: add tests for 'git config' completion, 2019-08-13), but let's do it directly here as well. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23help: correct logic error in combining --all and --guidesLibravatar Ævar Arnfjörð Bjarmason1-1/+6
The --all and --guides commands could be combined, which wouldn't have any impact on the output except for: git help --all --guides --no-verbose Listing the guide alongside that output was clearly not intended, so let's error out here. See 002b726a400 (builtin/help.c: add list_common_guides_help() function, 2013-04-02) for the initial implementation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23help: correct logic error in combining --all and --configLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Fix a bug in the --config option that's been there ever since its introduction in 3ac68a93fd2 (help: add --config to list all available config, 2018-05-26). Die when --all and --config are combined, combining them doesn't make sense. The code for the --config option when combined with an earlier refactoring done to support the --guide option in 65f98358c0c (builtin/help.c: add --guide option, 2013-04-02) would cause us to take the "--all" branch early and ignore the --config option. Let's instead list these as incompatible, both in the synopsis and help output, and enforce it in the code itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23help tests: add test for --config outputLibravatar Ævar Arnfjörð Bjarmason1-0/+13
Add a missing test for checking what the --config output added in ac68a93fd2 (help: add --config to list all available config, 2018-05-26) looks like. We should not be emitting anything except config variables and the brief usage information at the end here. The second test regexp here might not match three-level variables in general, as their second level could contain ".", but in this case we're always emitting what we extract from the documentation, so it's all strings like: foo.<name>.bar If we did introduce something like variable example content here we'd like this to break, since we'd then be likely to break the git-completion.bash. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23help: correct usage & behavior of "git help --guides"Libravatar Ævar Arnfjörð Bjarmason1-0/+4
As noted in 65f98358c0c (builtin/help.c: add --guide option, 2013-04-02) and a133737b809 (doc: include --guide option description for "git help", 2013-04-02) which introduced the --guide option, it cannot be combined with e.g. <command>. Change the command and the "SYNOPSIS" section to reflect that desired behavior. Now that we assert this in code we don't need to exhaustively describe the previous confusing behavior in the documentation either, instead of silently ignoring the provided argument we'll now error out. The "We're done. Ignore any remaining args" comment added in 15f7d494380 (builtin/help.c: split "-a" processing into two, 2013-04-02) can now be removed, it's obvious that we're asserting the behavior with the check of "argc". The "--config" option is still missing from the synopsis, it will be added in a subsequent commit where we'll fix bugs in its implementation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-14help: make sure local html page exists before calling external processesLibravatar Matthias Aßhauer1-0/+16
We check that git.html exists, regardless of the page the user wants to open. Checking whether the requested page exists instead gives us a smoother user experience in two use cases: 1) The requested page doesn't exist When calling a git command and there is an error, most users reasonably expect git to produce an error message on the standard error stream, but in this case we pass the filepath to git web--browse which passes it on to a browser (or a helper program like xdg-open or start that should in turn open a browser) without any error and many GUI based browsers or helpers won't output such a message onto the standard error stream. Especially the helper programs tend to show the corresponding error message in a message box and wait for user input before exiting. This leaves users in interactive console sessions without an error message in their console, without a console prompt and without the help page they expected. 2) git.html is missing for some reason, but the user asked for some other page We currently refuse to show any local html help page when we can't find git.html. Even if the requested help page exists. If we check for the requested page instead, we can show the user all available pages and only error out on those that don't exist. Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-10tests: remove most uses of test_i18ncmpLibravatar Ævar Arnfjörð Bjarmason1-1/+1
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-03help -a: improve and make --verbose defaultLibravatar Nguyễn Thái Ngọc Duy1-2/+2
When you type "git help" (or just "git") you are greeted with a list with commonly used commands and their short description and are suggested to use "git help -a" or "git help -g" for more details. "git help -av" would be more friendly and inline with what is shown with "git help" since it shows list of commands with description as well, and commands are properly grouped. "help -av" does not show everything "help -a" shows though. Add external command section in "help -av" for this. While at there, add a section for aliases as well (until now aliases have no UI, just "git config"). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21help: use command-list.txt for the source of guidesLibravatar Nguyễn Thái Ngọc Duy1-0/+6
The help command currently hard codes the list of guides and their summary in C. Let's move this list to command-list.txt. This lets us extract summary lines from Documentation/git*.txt. This also potentially lets us list guides in git.txt, but I'll leave that for now. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21help: add "-a --verbose" to list all commands with synopsisLibravatar Nguyễn Thái Ngọc Duy1-0/+9
This lists all recognized commands [1] by category. The group order follows closely git.txt. [1] We may actually show commands that are not built (e.g. if you set NO_PERL you don't have git-instaweb but it's still listed here). I ignore the problem because on Linux a git package could be split anyway. The "git-core" package may not contain git-instaweb even if it's built because it may end up in a separate package. We can't know anyway. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21git.c: convert --list-* to --list-cmds=*Libravatar Nguyễn Thái Ngọc Duy1-1/+1
Even if these are hidden options, let's make them a bit more generic since we're introducing more listing types shortly. The code is structured to allow combining multiple listing types together because we will soon add more types the 'builtins'. 'parseopt' remains separate because it has separate (SPC) to match git-completion.bash needs and will not combine with others. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-10help: use command-list.h for common command listLibravatar Nguyễn Thái Ngọc Duy1-0/+9
The previous commit added code generation for all_cmd_desc[] which includes almost everything we need to generate common command list. Convert help code to use that array instead and drop common_cmds[] array. The description of each common command group is removed from command-list.txt. This keeps this file format simpler. common-cmds.h will not be generated correctly after this change due to the command-list.txt format change. But it does not matter and common-cmds.h will be removed. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-05t0012: test "-h" with builtinsLibravatar Jeff King1-0/+12
Since commit 99caeed05 (Let 'git <command> -h' show usage without a git dir, 2009-11-09), the git wrapper handles "-h" specially, skipping any repository setup but still calling the builtin's cmd_foo() function. This means that every cmd_foo() must be ready to handle this case, but we don't have any systematic tests. This led to "git am -h" being broken for some time without anybody noticing. This patch just tests that "git foo -h" works for every builtin, where we see a 129 exit code (the normal code for our usage() helper), and that the word "usage" appears in the output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-30help: make option --help open man pages only for Git commandsLibravatar Ralf Thielow1-0/+8
If option --help is passed to a Git command, we try to open the man page of that command. However, we do it for both commands and concepts. Make sure it is an actual command. This makes "git <concept> --help" not working anymore, while "git help <concept>" still works. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-30help: introduce option --exclude-guidesLibravatar Ralf Thielow1-0/+44
Introduce option --exclude-guides to the help command. With this option being passed, "git help" will open man pages only for actual commands. Since we know it is a command, we can use function help_unknown_command to give the user advice on typos. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>