Re: Oddidies in the .mailmap parser & future syntax extensions

2 messages, 2 authors, 2021-09-13 · open the first message on its own page

Re: Oddidies in the .mailmap parser & future syntax extensions

From: Junio C Hamano <hidden>
Date: 2021-09-10 20:20:10

Ævar Arnfjörð Bjarmason [off-list ref] writes:
Who wants to use mailmap, *and* map one e-mail address to another, *and*
has an entry explicitly mapping the name, but *would* mind having git be
auto-smart and follow the chain of that explicit name mapping if there's
an entry after that with an an e-mail -> that-earlier-email mapping?
Would it make a difference if I point out that at least for our
project, we want to keep the .mailmap lines be sorted?  I suspect
that a "list must be mechanically sorted" requirement may make it
awkward to also have an "if name is missing, use the last matching
explicit name".  Also, it makes removing one entry among many for
the same person less straight-forward (if you are removing the one
that happens to be listed first, you need to move the name to the
next entry in order to avoid losing it).

Re: Oddidies in the .mailmap parser & future syntax extensions

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-09-13 04:09:59

On Fri, Sep 10 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
Who wants to use mailmap, *and* map one e-mail address to another, *and*
has an entry explicitly mapping the name, but *would* mind having git be
auto-smart and follow the chain of that explicit name mapping if there's
an entry after that with an an e-mail -> that-earlier-email mapping?
Would it make a difference if I point out that at least for our
project, we want to keep the .mailmap lines be sorted?
I just used git.git as a handy example. If the project wants to not use
some new shorthand syntax to make for easy sorting it can just not use
it. I don't think that should be an argument against the existence of
such a syntax for those who'd like it.
I suspect that a "list must be mechanically sorted" requirement may
make it awkward to also have an "if name is missing, use the last
matching explicit name".  Also, it makes removing one entry among many
for the same person less straight-forward (if you are removing the one
that happens to be listed first, you need to move the name to the next
entry in order to avoid losing it).
That's a good point, that E-Mail was written rather off-hand, and I see
from find_last_name_for_address_in_mailmap() that I probably had that
ordering in mind.

But given that point I think a shorthand like that would be equally or
more useful if we don't care about the order, the "more" being because
you'd be able to sort it in any way you like and still get the same
results.

I.e. when mapping:

    [off-list ref] [off-list ref]
    [off-list ref] [off-list ref]

We'll have fully parsed the file, and having also seen:

    Junio C Hamano [off-list ref] [off-list ref]

We can follow the chain and see that since [off-list ref] has
explicit wanted name mapping, that we should use that for say
[off-list ref], because it wants to map to [off-list ref], so
it should also get the name mapping.

Except if we had more than one name mapping, but that could/should also
be detected regardless of order.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help