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.
