On Sun, Sep 18, 2016 at 1:25 AM, René Scharfe <l....@web.de> wrote:
> Am 17.09.2016 um 14:51 schrieb Anatoly Borodin:
>> Hi All!
>> First bug:
>> git log -3 --pretty='%C(cyan)%C(auto)%h%C(auto)%d %s'
>> prints %h with the default color (normal yellow), but
>> git log -3 --pretty='%C(bold cyan)%C(auto)%h%C(auto)%d %s'
>> shows %h with bold yellow, as if only the color was reset, but not
>> the attributes (blink, ul, reverse also work this way). %d and %s are
>> printed with the right color both times.
>> Second bug, maybe related to the first one:
>> git log -3 --pretty='%C(bold cyan)%h%C(auto)%d %s %an %h %h %s'
>> The first line looks as expected. Well, almost: the '(' of %d is bold
>> The second line looks like this:
>> * %h, %s, %an with bold cyan;
>> * %h with bold yellow;
>> * %h with normal yellow and %s with normal white (default colors).
>> PS git version 2.9.2
> Well, in both cases you could add %Creset before %C(auto) to get what
> you want.
> I'm not sure how just how automatic %C(auto) is supposed to be, but you
> expected it do emit the reset for you, right? Sounds reasonable to me.
> The following patch implements that behavior.
> Duy, what do you think?
Even though letting some attributes before %C(auto) through sounds
interesting, I'd say it's a bit unpredictable, especially when the
main usage of %C(auto) is %d which could use plenty of colors. So yes,
your changes look good.