From: Jacob Keller Date: Wed, 21 Aug 2024 19:07:48 GMT Subject: Re: [PATCH v2 1/3] check-mailmap: accept "user@host" contacts Message-ID: In-Reply-To: On 8/21/2024 11:26 AM, Junio C Hamano wrote: > Josh Steadmon writes: > >>> test_expect_success 'check-mailmap bogus contact' ' >>> - test_must_fail git check-mailmap bogus >>> + cat >expect <<-EOF && >>> + >>> + 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 > that looks more globally routable address than a local-only > mailbox. Isn't it worth ensuring that we will keep treating them > the same way? > > Having said that ... > >>> -For each ``Name $$$$'' or ``$$$$'' 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 $$$$'', ``$$$$'', 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 without <@host> is a supported format. > Should we update the document, too? > Its supported by happenstance, but i didn't want to encourage it. > 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. > I prefer removing the test. In an ideal world, I think we would probably only accept actual or user@host, but I did not think I would create sufficiently correct parsing for addresses, so I left it out. I did try looking up what the rules for addresses are, but it looks like it got pretty complicated. I guess we could do very basic "it must have an @ symbol, but anything else goes? > Thanks. >