git/help.c, branch v2.23.2

Merge branch 'jk/help-unknown-ref-fix'

2019-06-13T20:19:42Z

Improve the code to show args with potential typo that cannot be interpreted as a commit-ish. * jk/help-unknown-ref-fix: help_unknown_ref(): check for refname ambiguity help_unknown_ref(): duplicate collected refnames

help_unknown_ref(): check for refname ambiguity

2019-05-15T01:58:02Z

When the user asks to merge "foo" and we suggest "origin/foo" instead, we do so by simply chopping off "refs/remotes/" from the front of the suggested ref. This is usually fine, but it's possible that the resulting name is ambiguous (e.g., you have "refs/heads/origin/foo", too). Let's use shorten_unambiguous_ref() to do this the right way, which should usually yield the same "origin/foo", but "remotes/origin/foo" if necessary. Note that in this situation there may be other options (e.g., we could suggest "heads/origin/foo" as well). I'll leave that up for debate; the focus here is just to avoid giving advice that does not actually do what we expect. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

help_unknown_ref(): duplicate collected refnames

2019-05-15T01:58:00Z

When "git merge" sees an unknown refname, we iterate through the refs to try to suggest some possible alternates. We do so with for_each_ref(), and in the callback we add some of the refnames we get to a string_list that is declared with NODUP, directly adding a pointer into the refname string our callback received. But the for_each_ref() machinery does not promise that the refname string will remain valid, and as a result we may print garbage memory. The code in question dates back to its inception in e56181060e (help: add help_unknown_ref(), 2013-05-04). But back then, the refname strings generally did remain stable, at least immediately after the for_each_ref() call. Later, in d1cf15516f (packed_ref_iterator_begin(): iterate using `mmapped_ref_iterator`, 2017-09-25), we started consistently re-using a separate buffer for packed refs. The fix is simple: duplicate the strings we intend to collect. We already call string_list_clear(), so the memory is correctly freed. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

completion: fix multiple command removals

2019-03-21T02:52:11Z

Commit 6532f3740b ("completion: allow to customize the completable command list", 2018-05-20) tried to allow multiple space-separated entries in completion.commands. To do this, it copies each parsed token into a strbuf so that the result is NUL-terminated. However, for tokens starting with "-", it accidentally passes the original non-terminated string, meaning that only the final one worked. Switch to using the strbuf. Reported-by: Todd Zullinger Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

git: read local config in --list-cmds

2019-03-21T02:52:11Z

Normally code that is checking config before we've decided to do setup_git_directory() would use read_early_config(), which uses discover_git_directory() to tentatively see if we're in a repo, and if so to add it to the config sequence. But list_cmds() uses the caching configset mechanism which rightly does not use read_early_config(), because it has no idea if it's being called early. Call setup_git_directory_gently() so we can pick up repo-level config (like completion.commands). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

help: align the longest command in the command listing

2019-01-31T23:27:35Z

"longest" is used to determine how many extra spaces we need to print to keep the command description aligned. For the longest command, we should print no extra space instead of one, or we'll get unaligned output like this (notice the "checkout" line): grow, mark and tweak your common history branch List, create, or delete branches checkout Switch branches or restore working tree files commit Record changes to the repository diff Show changes between commits, commit and ... merge Join two or more development histories together rebase Reapply commits on top of another base tip tag Create, list, delete or verify a tag ... Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

help -a: handle aliases with long names gracefully

2018-12-12T08:18:38Z

We take pains to determine the longest command beforehand, so that we can align the category column after printing the command names. However, then we re-use that value when printing the aliases. If any alias name is longer than the longest command name, we consequently try to add a negative number of spaces (but `mput_char()` does not expect any negative values and simply decrements until the value is 0, i.e. it tries to add close to 2**31 spaces). Let's fix this by adjusting the `longest` variable before printing the aliases. This fixes https://github.com/git-for-windows/git/issues/1975. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

help -a: improve and make --verbose default

2018-10-04T04:23:51Z

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

Merge branch 'hn/highlight-sideband-keywords'

2018-08-20T19:41:34Z

The sideband code learned to optionally paint selected keywords at the beginning of incoming lines on the receiving end. * hn/highlight-sideband-keywords: sideband: do not read beyond the end of input sideband: highlight keywords in remote sideband output

Merge branch 'mk/http-backend-content-length'

2018-08-17T20:09:57Z

The http-backend (used for smart-http transport) used to slurp the whole input until EOF, without paying attention to CONTENT_LENGTH that is supplied in the environment and instead expecting the Web server to close the input stream. This has been fixed. * mk/http-backend-content-length: t5562: avoid non-portable "export FOO=bar" construct http-backend: respect CONTENT_LENGTH for receive-pack http-backend: respect CONTENT_LENGTH as specified by rfc3875 http-backend: cleanup writing to child process