git/help.h, branch v2.20.2

help.h: fix coding style

2018-12-12T08:18:29Z

We want a space after the `while` keyword. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sideband: highlight keywords in remote sideband output

2018-08-08T22:20:09Z

The colorization is controlled with the config setting "color.remote". Supported keywords are "error", "warning", "hint" and "success". They are highlighted if they appear at the start of the line, which is common in error messages, eg. ERROR: commit is missing Change-Id The Git push process itself prints lots of non-actionable messages (eg. bandwidth statistics, object counters for different phases of the process). This obscures actionable error messages that servers may send back. Highlighting keywords in the sideband draws more attention to those messages. The background for this change is that Gerrit does server-side processing to create or update code reviews, and actionable error messages (eg. missing Change-Id) must be communicated back to the user during the push. User research has shown that new users have trouble seeing these messages. The highlighting is done on the client rather than server side, so servers don't have to grow capabilities to understand terminal escape codes and terminal state. It also consistent with the current state where Git is control of the local display (eg. prefixing messages with "remote: "). The highlighting can be configured using color.remote. configuration settings. Since the keys are matched case insensitively, we match the keywords case insensitively too. Finally, this solution is backwards compatible: many servers already prefix their messages with "error", and they will benefit from this change without requiring a server update. By contrast, a server-side solution would likely require plumbing the TERM variable through the git protocol, so it would require changes to both server and client. Helped-by: Duy Nguyen Signed-off-by: Han-Wen Nienhuys Signed-off-by: Junio C Hamano

completion: drop the hard coded list of config vars

2018-05-29T05:51:28Z

The new help option --config-for-completion is a machine friendlier version of --config where all the placeholders and wildcards are dropped, leaving only the good, completable prefixes for git-completion.bash to consume. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

help: add --config to list all available config

2018-05-29T05:51:28Z

Sometimes it helps to list all available config vars so the user can search for something they want. The config man page can also be used but it's harder to search if you want to focus on the variable name, for example. This is not the best way to collect the available config since it's not precise. Ideally we should have a centralized list of config in C code (pretty much like 'struct option'), but that's a lot more work. This will do for now. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

completion: allow to customize the completable command list

2018-05-21T04:23:14Z

By default we show porcelain, external commands and a couple others that are also popular. If you are not happy with this list, you can now customize it a new config variable. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

help: use command-list.txt for the source of guides

2018-05-21T04:23:14Z

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 Signed-off-by: Junio C Hamano

help: add "-a --verbose" to list all commands with synopsis

2018-05-21T04:23:14Z

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 Signed-off-by: Junio C Hamano

git: support --list-cmds=list-

2018-05-21T04:23:14Z

This allows us to select any group of commands by a category defined in command-list.txt. This is an internal/hidden option so we don't have to be picky about the category name or worried about exposing too much. This will be used later by git-completion.bash to retrieve certain command groups. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

completion: implement and use --list-cmds=main,others

2018-05-21T04:23:14Z

This is part of the effort to break down and provide commands by category in machine-readable form. This could be helpful later on when completion script switches to use --list-cmds for selecting completable commands. It would be much easier for the user to choose to complete _all_ commands instead of the default selection by passing different values to --list-cmds in git-completino.bash. While at there, replace "git help -a" in git-completion.bash with --list-cmds since it's better suited for this task. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

help: add help_unknown_ref()

2013-05-08T22:31:54Z

When the user gives an unknown string to a command that expects to get a ref, we could be more helpful than just saying "that's not a ref" and die. Add helper function help_unknown_ref() to take care of displaying an error message along with a list of suggested refs the user might have meant. An interaction with "git merge" might go like this: $ git merge foo merge: foo - not something we can merge Did you mean one of these? origin/foo upstream/foo Signed-off-by: Vikrant Varma Signed-off-by: Junio C Hamano