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

[Junio C Hamano <gitster@pobox.com>]

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. Make the colourization of these
> state indicators consistent by clearing any colour before printing the
> short upstream state indicator, as this immediately follows the last
> coloured indicator.
>
> Signed-off-by: Joakim Petersen <joak-pet@online.no>
> ---

> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 87b2b916c0..dfd6cef35f 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()
>  	if [ -n "$u" ]; then
>  		u="$bad_color$u"
>  	fi
> +	p="$c_clear$p"
>  	r="$c_clear$r"
>  }

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.