From: Eric Sunshine <sunshine@sunshineco.com>
Date: Fri, 12 Jul 2013 06:24:43 GMT
Subject: Re: [PATCH v2 1/4] builtin: add git-check-mailmap command
Message-ID: <CAPig+cTwXe7rSKUgJPVHbAvrxYbmL77xNXtLyUeRnd8Taxtrdw@mail.gmail.com>
In-Reply-To: <7vbo68pbwm.fsf@alter.siamese.dyndns.org>

On Fri, Jul 12, 2013 at 1:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>>>         For each contact information (either in the form of ``Name
>>>         <user@host>'' or ...)
>>>
>>> in order to clarify that the two forms of input is what you call
>>> "contact information".
>>
>> Is this easier to read?
>>
>>     For each ``Name $$<user@host>$$'' or ``$$<user@host>$$'' from the
>>     command-line or standard input (when using `--stdin`), print a line
>>     showing either the canonical name and email address (see "Mapping
>>     Authors" below), or the input ``Name $$<user@host>$$'' or
>>     ``$$<user@host>$$'' if there is no mapping for that person.
>
> I find it easier than your original, but I do not know if you would
> want to repeat the "Name... or <user@host>" at the end.  It does not
> seem to add much useful information and is distracting.

Next attempt:

    For each ``Name $$<user@host>$$'' or ``$$<user@host>$$'' from the
    command-line or standard input (when using `--stdin`) look up the
    person's canonical name and email address (see "Mapping Authors"
    below). If found, print them; otherwise print the input as-is.

>> In check-attr, null_term_line indicates that _input_ lines are
>> null-terminated. In check-ignore, null_term_lines is overloaded (and
>> perhaps abused) to mean that both _input_ and _output_ lines are
>> null-terminated.
>
> That is unfortunate but it is good that you found the breakage.  As
> we do not have --nul-terminated-input and --nul-terminated-output
> options separtely, -z should apply to both input and output.  What
> b4666852 (check-attr: Add --stdin option, 2008-10-07) did is broken.

I can make git-check-mailmap behave this way, however, other than
git-check-ignore (which is quite new), there doesn't seem to be any
precedence (that I can find) anywhere else in git which ties input and
output null-termination to a single switch. Is it desirable to do so
or should the user have more fine-grained control? ("xargs -0" comes
to mind when thinking of a null-termination input switch.)

> Also "git check-ignore -h" advertises "-z" as only affecting "--stdin",
> which is also wrong.  It does affect both input and output as it should,
> so it should be described as such, I think.

I also noticed this. (It was copied from check-attr.c).