git/contrib/completion, branch v2.40.2

completion: add case-insensitive match of pseudorefs

2022-11-30T00:58:06Z

When GIT_COMPLETION_IGNORE_CASE is set, also allow lowercase completion text like "head" to match uppercase HEAD and other pseudorefs. Signed-off-by: Alison Winters Signed-off-by: Junio C Hamano

completion: add optional ignore-case when matching refs

2022-11-30T00:58:06Z

If GIT_COMPLETION_IGNORE_CASE is set, --ignore-case will be added to git for-each-ref calls so that refs can be matched case insensitively, even when running on case sensitive filesystems. Signed-off-by: Alison Winters Signed-off-by: Junio C Hamano

git-prompt: show presence of unresolved conflicts at command prompt

2022-08-19T17:58:40Z

If GIT_PS1_SHOWCONFLICTSTATE is set to "yes", show the word "CONFLICT" on the command prompt when there are unresolved conflicts. Example prompt: (main|CONFLICT) Signed-off-by: Justin Donnelly Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

git-prompt: fix expansion of branch colour codes

2022-06-10T16:41:49Z

Because of the wrapping of the branch name variable $b, the colour codes in the variable don't get applied, but are instead printed directly in the output. Move the wrapping of $b to before colour codes are inserted to correct this. Revert move of branch name colour codes in tests, as the branch name is now coloured after the wrapping instead of before. Signed-off-by: Joakim Petersen Signed-off-by: Junio C Hamano

git-prompt: make colourization consistent

2022-06-07T16:08:39Z

The short upstream state indicator inherits the colour of the last short state indicator before it (if there is one), and the sparsity state indicator inherits this colour as well. This behaviour was introduced by 0ec7c23cdc6 (git-prompt: make upstream state indicator location consistent, 2022-02-27), while before this change the aforementioned indicators were white/the default text colour. Some examples to illustrate this behaviour (assuming all indicators are enabled and colourization is on): * If there is something in the stash, both the '$' and the short upstream state indicator following it will be blue. * If the local tree has new, untracked files and there is nothing in the stash, both the '%' and the short upstream state indicator will be red. * If all local changes are added to the index and the stash is empty, both the '+' and the short upstream state indicator following it will be green. * If the local tree is clean and there is nothing in the stash, the short upstream state indicator will be white/${default text colour}. This appears to be an unintended side-effect of the change, and makes little sense semantically (e.g. why is it bad to be in sync with upstream when you have uncommitted local changes?). The cause of the change in colourization is that previously, the short upstream state indicator appeared immediately after the rebase/revert/bisect/merge state indicator (note the position of $p in $gitstring): local f="$h$w$i$s$u" local gitstring="$c$b${f:+$z$f}${sparse}$r$p" Said indicator is prepended with the clear colour code, and the short upstream state indicator is thus also uncoloured. Now, the short upstream state indicator follows the sequence of colourized indicators, without any clearing of colour (again note the position of $p, now in $f): local f="$h$w$i$s$u$p" local gitstring="$c$b${f:+$z$f}${sparse}$r${upstream}" If the user is in a sparse checkout, the sparsity state indicator follows a similar pattern to the short upstream state indicator. However, clearing colour of the colourized indicators changes how the sparsity state indicator is colourized, as it currently inherits (and before the change referenced also inherited) the colour of the last short state indicator before it. Reading the commit message of the change that introduced the sparsity state indicator, afda36dbf3b (git-prompt: include sparsity state as well, 2020-06-21), it appears this colourization also was unintended, so clearing the colour for said indicator further increases consistency. Make the colourization of these state indicators consistent by making all colourized indicators clear their own colour. Make colouring of $c dependent on it not being empty, as it is no longer being used to colour the branch name. Move clearing of $b's prefix to before colourization so it gets cleared properly when colour codes are inserted into it. These changes make changing the layout of the prompt less prone to unintended colour changes in the future. Change coloured Bash prompt tests to reflect the colourization changes: * Move the colour codes to wrap the expected content of the expanded $__git_ps1_branch_name in all tests. * Insert a clear-colour code after the symbol for the first indicator in "prompt - bash color pc mode - dirty status indicator - dirty index and worktree", to reflect that all indicators should clear their own colour. Signed-off-by: Joakim Petersen Signed-off-by: Junio C Hamano

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