Joakim Petersen <joak-pet@xxxxxxxxx> writes:
> 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. Make the colourization of these
> state indicators consistent by making all colourized indicators clear
> their own colour.
> As of 0ec7c23cdc6 (git-prompt: make upstream state indicator location
> consistent, 2022-02-27), colourization in the output of __git_ps1 has
> changed such that the short upstream state indicator inherits the colour
> of the last short state indicator before it (if there is one), while
> before this change it was 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
looong space?
> 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 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.
Here, after explaining how bad the current situation is, like the
above, is a good place to say what we do, i.e. "teach indicators to
clear after themselves".
> Colouring of $c was made dependent on it not being empty, as it is no
> longer being used to colour the branch name. Removal of $b's prefix was
> moved to before the colourization so it gets cleared properly now that
> colour codes are inserted into it.
>
> Due to colour clearing being moved into the variables for each coloured
> indicator, the tests for the coloured Bash prompt had to be changed:
> * All colour tests now have the colour codes around the expected
> content of the expanded $__git_ps1_branch_name variable instead of
> the unexpanded variable in the string.
> * The test with two indicators had a clear-colour code inserted after
> the symbol for the first indicator, since all indicators clear their
> own colours now.
>
> Signed-off-by: Joakim Petersen <joak-pet@xxxxxxxxx>
> ---
Nicely written.
Will queue.
Thanks.
