Re: [RFC PATCH] git-prompt: make colourization consistent
- From
Joakim Petersen <joak-pet@online.no>
- Date
- Jun 1, 2022, 18:32 UTC
- Message-ID
- <47ba2296-10f3-4590-dbf5-38d92ed3e29e@online.no>
- In-Reply-To
- <xmqq7d60tfyd.fsf@gitster.g>
On 01/06/2022 20:07, Junio C Hamano wrote:
Show 29 quoted lines
> 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.