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

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

On 01/06/2022 20:07, Junio C Hamano wrote:
> Hmph, am I correct to understand that the general flow of __git_ps1 is
> 
>   (1) various pieces of information like $h, $w, $i, $s, $r, $b, $p,
>       etc.  are declared "local" and values computed for them,
>       either inside __git_ps1() itself, or by various helper
>       functions it calls;
> 
>   (2) When GIT_PS1_SHOWCOLORHINTS is in effect, we may call the
>       __git_ps1_colorize_gitstring helper (which is touched by the
>       above hunk), that modifies these variables with color codes.
>       Upon entry to this helper function, these variables prepared in
>       (1) have no color effects.  Upon leaving, they do.
> 
>   (3) Finally, the PS1 is asseembled by concatenating these
>       variables, whose text was prepared in (1) and then prefixed by
>       color codes in (2), one of the earliest steps begins like so:
> 
>       local f="$h$w$i$s$u"
>       local gitstring="$c$b${f:+$z$f}${sparse}$r$p"
> 
> In the final step of formulation, $p immediately follows $r in the
> resulting $PS1, and the existing code at the end of the (2) prefixes
> $c_clear before $r, and $r before such prefixing is free of coloring,
> so it is curious how this patch makes difference (other than emitting
> $c_clear one more time).  Unless there is a use of $p that does not
> immediately follow $r, that is.
> 
> Thanks.
> 

Your understanding is correct for the flow before the change I
referenced (0ec7c23cdc6 (git-prompt: make upstream state
indicator location consistent, 2022-02-27)), however, that commit
changed the definition of $f and $gitstring to

	local f="$h$w$i$s$u$p"
	local gitstring="$c$b${f:+$z$f}${sparse}$r${upstream}"

This makes it so $p is no longer immediately preceded by $r, but rather
$u, which, like all the preceding variables, except $h, will be
colourized if enabled.