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

> After thinking it again, I actually am OK with the original coloring
> code structure.  The rule is "you always counter whatever color
> settings left behind by somebody who came before you".
> 
> As long as the color effect you use is not additive (e.g. if the
> final product is $a$b, and $a is prefixed with $c_red and $b is
> prefixed with $c_blue, an additive coloring scheme may end up
> painting b in purple), we'll save number of $c_clear we would need
> to emit.  Plain colors are probably not additive, but some
> attributes are, so this is more brittle than "always reset to the
> base state" rule, but it may be more desirable in practice.
> 
> I have no strong preference either way.  But if we are to go that
> route, we definitely need to make sure that the last element added
> to gitstring is followed by $c_reset, by doing something like the
> attached patch.  Currently, $r has unconditional $c_clear in front
> of it, and $upstream is never colored, and that is the only thing
> that is saving us from leftover color bleeding into whatever comes
> after the prompt.