Re: [RFC/PATCH 1/4] builtin: add git-check-mailmap command

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Jul 11, 2013 at 12:50 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> +       maybe_flush_or_die(stdout, "contact to stdout");
>>
>> On error this function will print
>>
>> write failure on 'contact to stdout'
>>
>> maybe maybe_flush_or_die(stdout, "write contact to stdout") or
>> something? From i18n point of view, maybe_flush_or_die should not
>> compose a sentence this way. Let the second argument be a complete
>> sentence so that translators have more freedom. But that's a different
>> issue.
>
> Indeed, it's not ideal. I chose "contact to stdout" for consistency
> with other callers, not because of a fondness for it.
>
>   % git grep maybe_flush_or_die
>   builtin/blame.c: maybe_flush_or_die(stdout, "stdout");
>   builtin/check-attr.c: maybe_flush_or_die(stdout, "attribute to stdout");
>   builtin/check-attr.c: maybe_flush_or_die(stdout, "attribute to stdout");
>   builtin/check-ignore.c: maybe_flush_or_die(stdout, "check-ignore to stdout");
>   builtin/check-ignore.c: maybe_flush_or_die(stdout, "ignore to stdout");
>   builtin/hash-object.c: maybe_flush_or_die(stdout, "hash to stdout");
>   builtin/rev-list.c: maybe_flush_or_die(stdout, "stdout");
>   log-tree.c: maybe_flush_or_die(stdout, "stdout");
>
> They seem pretty evenly split between just "stdout" and "foo to
> stdout". (I actually prefer plain "stdout" and will happily change it
> to that.)

Then probably stick to the convention. If this i18n thing is fixed, it
has to be fixed everywhere anyway.
-- 
Duy