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

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

This is not a new issue, but seeing this:

 	if [ $detached = no ]; then
 		branch_color="$ok_color"
 	else
 		branch_color="$bad_color"
 	fi
 	c="$branch_color$c"
 
 	z="$c_clear$z"
 	if [ "$w" = "*" ]; then
 		w="$bad_color$w"
 	fi
 	if [ -n "$i" ]; then
 		i="$ok_color$i"
 	fi
 	if [ -n "$s" ]; then
 		s="$flags_color$s"
 	fi
 	if [ -n "$u" ]; then
 		u="$bad_color$u"
 	fi
+	if [ -n "$p" ]; then
+		p="$c_clear$p"
+	fi
+	if [ -n "$sparse" ]; then
+		sparse="$c_clear$sparse"
+	fi
 	r="$c_clear$r"
 }

it makes me wonder if the more forward looking and future-proof way
that is resistant to any future and random reshuffling like what
0ec7c23c (git-prompt: make upstream state indicator location
consistent, 2022-02-27) did would be to make it a rule to maintain
that there is no coloring by default, and when any of these tokens
like w, i, s, ... are not empty, enclose them inside "color-on" and
"color-off" sequence.

For example, 

 	if [ "$w" = "*" ]; then
 		w="$bad_color$w"
 	fi

would mean $w, when it is "*", would cause gitstring to contain an
asterisk that is painted in $bad_color, but ALSO causes whatever
that happens to come AFTER $w in gitstring to be painted in the same
color UNLESS it tries to protect itself.  Right now, $w may be
immediately followed by $i, and $i does protect itself by prefixing
with $ok_color, but if $i is empty, $w's coloring will extend to $s.

So, if we did this instead:

- 	z="$c_clear$z"
 	if [ "$w" = "*" ]; then
- 		w="$bad_color$w"
+ 		w="$bad_color$w$c_clear"
 	fi

and make similar changes to everything else we see above, we
probably can lose the ones that prefix with $c_clear, because each
token that paints itself in unusual color is now responsible for
returning the terminal state to normal with the $c_clear sequence
after it is done with it.  We do not have to special case sparse, p,
or r in this helper function at all if we go that route, no?

If the helper were written that way, then reshuffling the order of
the tokens done in 0ec7c23c (git-prompt: make upstream state
indicator location consistent, 2022-02-27) wouldn't have made the
patch under discussion necessary at all, which is what I see is
valuable from the "maintainability" point of view.