git/contrib/completion, branch v2.36.2

Merge branch 'jd/prompt-upstream-mark'

2022-03-31T01:01:11Z

Tweaks in the command line prompt (in contrib/) code around its GIT_PS1_SHOWUPSTREAM feature. * jd/prompt-upstream-mark: git-prompt: put upstream comments together git-prompt: make long upstream state indicator consistent git-prompt: make upstream state indicator location consistent git-prompt: rename `upstream` to `upstream_type`

git-prompt: put upstream comments together

2022-03-23T20:07:50Z

Commit 6d158cba28 (bash completion: Support "divergence from upstream" messages in __git_ps1, 2010-06-17) introduced support for indicating divergence from upstream in the PS1 prompt. The comments at the top of git-prompt.sh that were introduced with that commit are several paragraphs long. Over the years, other comments have been inserted in between the paragraphs relating to divergence from upstream. This commit puts the comments relating to divergence from upstream back together. Signed-off-by: Justin Donnelly Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git-prompt: make long upstream state indicator consistent

2022-03-23T20:07:45Z

Use a pipe as a separator before long upstream state indicator. This is consistent with long state indicators for sparse and in-progress operations (e.g. merge). For comparison, `__git_ps1` examples without upstream state indicator: (main) (main %) (main *%) (main|SPARSE) (main %|SPARSE) (main *%|SPARSE) (main|SPARSE|REBASE 1/2) (main %|SPARSE|REBASE 1/2) Note that if there are long state indicators, they appear after short state indicators if there are any, or after the branch name if there are no short state indicators. Each long state indicator begins with a pipe (`|`) as a separator. Before/after examples with long upstream state indicator: | Before | After | | ------------------------------- | ------------------------------- | | (main u=) | (main|u=) | | (main u= origin/main) | (main|u= origin/main) | | (main u+1) | (main|u+1) | | (main u+1 origin/main) | (main|u+1 origin/main) | | (main % u=) | (main %|u=) | | (main % u= origin/main) | (main %|u= origin/main) | | (main % u+1) | (main %|u+1) | | (main % u+1 origin/main) | (main %|u+1 origin/main) | | (main|SPARSE u=) | (main|SPARSE|u=) | | (main|SPARSE u= origin/main) | (main|SPARSE|u= origin/main) | | (main|SPARSE u+1) | (main|SPARSE|u+1) | | (main|SPARSE u+1 origin/main) | (main|SPARSE|u+1 origin/main) | | (main %|SPARSE u=) | (main %|SPARSE|u=) | | (main %|SPARSE u= origin/main) | (main %|SPARSE|u= origin/main) | | (main %|SPARSE u+1) | (main %|SPARSE|u+1) | | (main %|SPARSE u+1 origin/main) | (main %|SPARSE|u+1 origin/main) | Signed-off-by: Justin Donnelly Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git-prompt: make upstream state indicator location consistent

2022-03-23T20:07:40Z

Make upstream state indicator location more consistent with similar state indicators (e.g. sparse). Group the short upstream state indicator (`=`, `<`, `>`, or `<>`) with other short state indicators immediately after the branch name. Previously short and long upstream state indicators appeared after all other state indicators. Use a separator (`SP` or `GIT_PS1_STATESEPARATOR`) between branch name and short upstream state indicator. Previously the short upstream state indicator would sometimes appear directly adjacent to the branch name instead of being separated. For comparison, `__git_ps1` examples without upstream state indicator: (main) (main %) (main *%) (main|SPARSE) (main %|SPARSE) (main *%|SPARSE) (main|SPARSE|REBASE 1/2) (main %|SPARSE|REBASE 1/2) Note that if there are short state indicators, they appear together after the branch name and separated from it by `SP` or `GIT_PS1_STATESEPARATOR`. Before/after examples with short upstream state indicator: | Before | After | | ---------------- | ---------------- | | (main=) | (main =) | | (main|SPARSE=) | (main =|SPARSE) | | (main %|SPARSE=) | (main %=|SPARSE) | Signed-off-by: Justin Donnelly Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git-prompt: rename `upstream` to `upstream_type`

2022-03-23T20:07:26Z

In `__git_ps1_show_upstream` rename the variable `upstream` to `upstream_type`. This allows `__git_ps1_show_upstream` to reference a variable named `upstream` that is declared `local` in `__git_ps1`, which calls `__git_ps1_show_upstream`. Signed-off-by: Justin Donnelly Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

completion: tab completion of filenames for 'git restore'

2022-03-16T00:21:22Z

If no --args are present after 'git restore', it assumes that you want to tab-complete one of the files with unstaged uncommitted changes. If a file has been staged, we don't want to list it, as restoring those requires a slightly more complex `git restore --staged`, so we only list those files that are --modified. While --committable also looks like a good candidate, that includes changes that have been staged. Signed-off-by: David Cantrell Signed-off-by: Junio C Hamano

Merge branch 'ab/complete-show-all-commands'

2022-02-18T00:25:06Z

The command line completion script (in contrib/) learned to complete all Git subcommands, including the ones that are normally hidden, when GIT_COMPLETION_SHOW_ALL_COMMANDS is used. * ab/complete-show-all-commands: completion: add a GIT_COMPLETION_SHOW_ALL_COMMANDS completion tests: re-source git-completion.bash in a subshell

completion: handle unusual characters for sparse-checkout

2022-02-08T18:15:43Z

Update the __gitcomp_directories method to de-quote and handle unusual characters in directory names. Although this initially involved an attempt to re-use the logic in __git_index_files, this method removed subdirectories (e.g. folder1/0/ became folder1/), so instead new custom logic was placed directly in the __gitcomp_directories method. Note there are two tests for this new functionality - one for spaces and accents and one for backslashes and tabs. The backslashes and tabs test uses FUNNYNAMES to avoid running on Windows. This is because: 1. Backslashes are explicitly not allowed in Windows file paths. 2. Although tabs appear to be allowed when creating a file in a Windows bash shell, they actually are not renderable (and appear as empty boxes in the shell). Co-authored-by: Johannes Schindelin Co-authored-by: Lessley Dennington Helped-by: Ævar Arnfjörð Bjarmason Signed-off-by: Lessley Dennington Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano

completion: improve sparse-checkout cone mode directory completion

2022-02-08T18:15:43Z

Use new __gitcomp_directories method to complete directory names in cone mode sparse-checkouts. This method addresses the caveat of poor performance in monorepos from the previous commit (by completing only one level of directories). The unusual character caveat from the previous commit will be fixed by the final commit in this series. Co-authored-by: Elijah Newren Co-authored-by: Lessley Dennington Signed-off-by: Lessley Dennington Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano

completion: address sparse-checkout issues

2022-02-08T18:15:42Z

Correct multiple issues with tab completion of the git sparse-checkout command. These issues were: 1. git sparse-checkout previously resulted in an incomplete list of subcommands (it was missing reapply and add). 2. Subcommand options were not tab-completable. 3. git sparse-checkout set and git sparse-checkout add showed both file names and directory names. While this may be a less surprising behavior for non-cone mode, cone mode sparse checkouts should complete only directory names. Note that while the new strategy of just using git ls-tree to complete on directory names is simple and a step in the right direction, it does have some caveats. These are: 1. Likelihood of poor performance in large monorepos (as a result of recursively completing directory names). 2. Inability to handle paths containing unusual characters. These caveats will be fixed by subsequent commits in this series. Signed-off-by: Lessley Dennington Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano