From: Joakim Petersen Date: Wed, 01 Jun 2022 18:32:31 GMT Subject: Re: [RFC PATCH] git-prompt: make colourization consistent Message-ID: <47ba2296-10f3-4590-dbf5-38d92ed3e29e@online.no> In-Reply-To: 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.