From: Junio C Hamano Date: Fri, 10 Sep 2021 18:11:45 GMT Subject: Re: Oddidies in the .mailmap parser & future syntax extensions Message-ID: In-Reply-To: <877dfocps2.fsf@evledraar.gmail.com> Ævar Arnfjörð Bjarmason writes: > [Changed subject] [jc: culled CC addresses] > I'd expect: > > Foo Bar > > To be an alias/shorthand for: > > Foo Bar OK. > More annoying is that this: > > New > > > Doesn't mean the same as: > ... > I.e. I'd expect the name to map to the empty string, *unless* we saw an > earlier address, i.e. just as we do for the first bar -> foo line (we > map it to a name of "New", we don't map it to an empty name). You expect the first one to map (anyname, ) to ("New", ) and you describe the second one does not map the human-readable part to "New", but it is unclear what the code does, or why you expect it to map to "" (or what your expectation is, for that matter, exactly---do you want an empty string, or do you want "New", or something else???). FWIW, if we were designing it from scratch, I'd expect the second one to map (anyname, ) to ($1, ), keeping the human-readable part as-is and only map the e-mail part. Or do you expect that when these two entries appear together, the first entry with "New" is carried over to the second entry? > Doing that would be strictly backwards compatible, i.e. now we'll > entirely ignore the 3rd E-Mail address. It does mean we also > accidentally support things like: > > New # A comment, because we ignore everything after the 2nd address > > But don't tell anyone I told you that :) But that is something that > might technically have inadvertently closed the door to future syntax > extensions, but we could probably do them anyway, or at worst have some > heuristic. I vaguely recall that it was not an accident but a deliberate feature to allow comments, but don't tell anyone I told you that.