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

[Taylor Blau <me@ttaylorr.com>]

Hi Ariadne,

On Thu, Aug 08, 2019 at 10:21:02PM -0500, Ariadne Conill wrote:
> Hello,
>
> On Thu, Aug 8, 2019 at 10:07 PM Phil Hord <phil.hord@gmail.com> wrote:
> >
> > 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.
>
> This is my point exactly!  My motive for improving this behaviour is
> entirely irrelevant, honestly.  I regret ever bringing it up elsewhere
> in the discussions, as it's completely irrelevant.

Yeah, I think that this makes much more sense (at least to me) as an
issue separate from the deadname rewriting topic. If nothing else, this
makes 'git log' act like 'git shortlog', which only makes sense.

> > > > >  - 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.
>
> I'd be open to looking into adding support for hashing the e-mail for
> cases like this if people are interested.  The
> firstname.lastname@company.com case is certainly a tough one to crack
> otherwise, but I think that a solution that works for most cases still
> is useful.  In the meantime, I think it makes sense to let people
> decide whether they wish to use mailmap for this purpose, based on
> their own understanding of the risks involved.

Yep. Totally agreed, and thank you for these patches.

> Ariadne

Thanks,
Taylor