On Sun, Feb 7, 2016 at 1:13 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> On Sat, Feb 6, 2016 at 10:20 AM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote:
>> On Fri, Feb 5, 2016 at 3:55 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote:
>>>> +static void color_atom_parser(struct used_atom *atom, const char *color_value)
>>>> +{
>>>> + if (!color_value)
>>>> + die(_("expected format: %%(color:<color>)"));
>>>> + if (color_parse(color_value, atom->u.color) < 0)
>>>> + die(_("invalid color value: %s"), atom->u.color);
>>>
>>> Shouldn't this be:
>>>
>>> die(_("invalid color value: %s"), color_value);
>>>
>>> ?
>>
>> Oops. You're right, it should.
>> Also the error is reported already in color_parse(...), so seems duplicated.
>>
>> git for-each-ref --format="%(color:sfadf)%(align:middle,30)%(refname)%(end)"
>> error: invalid color value: sfadf
>> fatal: invalid color value: sfadf
>>
>> What would be an ideal way around this?
>
> According to f6c5a29 (color_parse: do not mention variable name in
> error message, 2014-10-07), the doubled diagnostic messages are
> intentional, so I don't think you need to do anything about it in this
> series. If you want to make the "fatal" message a bit more helpful,
> you could add a %(color:) annotation, like this:
>
> die(_("unrecognized color: %%(color:%s)"), color_value);
>
> which would give you the slightly more helpful:
>
> error: invalid color value: sfadf
> fatal: unrecognized color: %(color:sfadf)
That seems to be a good way around the repetitive message.
will add thanks.
--
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