On Tue, Aug 11, 2015 at 11:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>
>> @@ -1283,9 +1279,11 @@ void show_ref_array_item(struct ref_array_item *info, const char *format, int qu
>> if (color_parse("reset", color) < 0)
>> die("BUG: couldn't parse 'reset' as a color");
>> resetv.s = color;
>> - print_value(&resetv, quote_style);
>> + format_quote_value(&resetv, quote_style, &output);
>
> Mental note: I _think_ the logic to scan the string and set
> need_color_reset_at_eol that happens at the beginning can be removed
> once the code fully utilizes formatting-state information. A
> coloring atom would leave a bit in the formatting state to say that
> the line color has been changed to something other than reset, and
> then this "at the end of line" code can decide if that is the case
> and add a "reset" thing here (i.e. the code inside the "if
> (need_color_reset_at_eol)" block shown here does not need to change,
> but the "if" condition would).
>
>
This could be done, when we implement color as a state :) Thanks for the note
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html