Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

From: Phil Hord <phil.hord@gmail.com>
Date: Aug 9, 2019, 03:07 UTC
Message-ID: <CABURp0oFNWfWEwnkjV1+Tag91HTRBCaJjyvc8CXtPGu78DhtSw@mail.gmail.com>
In-Reply-To: <20190809020732.GA89008@syl.lan>

The issue of deadnaming aside, turning on log.mailmap by default is the sensible thing to do given that other Git features already honor it that way. Having it ignored-by-default (but only sometimes) just adds confusion when a mailmap is available.

Show 16 quoted lines

> > >  - The '.mailmap' provides a list of transgender individuals, along
> > >    with their deadname, which can be used to harass them.
> >
> > This is potentially a problem but it's not as bad as you depict.  A
> > mailmap rule can match against e-mail only, which is precisely what I
> > have done in my projects.
>
> Ah, I may be severely mistaken -- my memory was that '.mailmap'
> rewriting could be used to rewrite both name and email, not merely
> email. I thought that records could take:
>
>   A U Thor <author@xample.com> -> B C Xyzz <newname@example.com>
>
> instead of canonicalizing by email alone. If this is the case, then I
> completely agree and share the opinion that this is not as bad as I
> originally depicted.

The long form you give there is to be used in case the old email address is not a unique key. See 'git help shortlog'.

The problem we have at work is that one woman's old email address includes her deadname, like <firstname.lastname@company.com>. I will leave it up to her whether she chooses to be listed explicitly in the mailmap. I have wondered if we should permit hashed email addresses to be used for this specific case, but this also has its drawbacks.

Phil