Re: [PATCH v2 1/3] check-mailmap: accept "user@host" contacts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Josh Steadmon <steadmon@xxxxxxxxxx> writes:

>>  test_expect_success 'check-mailmap bogus contact' '
>> -	test_must_fail git check-mailmap bogus
>> +	cat >expect <<-EOF &&
>> +	<bogus>
>> +	EOF
>> +	git check-mailmap bogus >actual &&
>> +	test_cmp expect actual
>>  '
>
> I think I'd just remove this test case altogether, IIUC it' doesn't
> provide any additional value vs. the "check-mailmap simple address: no
> mapping" test below.

Sorry, but I do not follow.  The other one is <bogus@xxxxxxxxxx>
that looks more globally routable address than a local-only <bogus>
mailbox.  Isn't it worth ensuring that we will keep treating them
the same way?

Having said that ...

>> -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.
>> +For each ``Name $$<user@host>$$'', ``$$<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.

... it seems that <user> without <@host> is a supported format.
Should we update the document, too? 

If the @host-less name is meant to trigger a random unspecified
behaviour, whatever the code happens to do, that is perfectly fine,
but then we probably should not be etching it in the stone by
writing a test for it.  So because of a  reason that is completely
different from yours, I'd support removal of the "bogus" test, if
that is the case.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux