Re: [PATCH v7] git-prompt: make colourization consistent

> 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 <joak-pet@online.no>
> ---
> Changes since v6:
>  * Remove repeated statements and move all explanation of what the patch
>    does to the latter part of the message.
>  * Add a short statement about other benefits of the behavioural change.