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

[Joakim Petersen <joak-pet@online.no>]

On 07/06/2022 18:22, Junio C Hamano wrote:
> Joakim Petersen <joak-pet@online.no> 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. 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.
> 
> The handling of $w is different from the original (it used to be
> that only '*' was painted in red, now any non-empty strings do), but
> '*' is the only value that can be assigned to $w, so there is no
> material difference.
> 
> Looking good.  Will queue.  Thanks.
> 

The change regarding $w was mentioned below --- for v5:
 > Changes since v4:
 >  * The check for whether to colourize $w has been altered to match the
 >    checks for the other indicators.
I'll add a mention of this to the commit message as well.