On 8/21/2024 11:26 AM, Junio C Hamano wrote: > 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? > 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 <user@host> 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. >
