Re: Wildcards in mailmap to hide transgender people's deadnames

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Sep 21 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I think it would be irresponsible of us to provide a feature that looks
>> as though it can in any way mitigate those concerns.
>>
>> If you're someone that's worried about being harassed if someone makes
>> the link from your previous identity Y to your current identity X where
>> you already have Y as part of a public git history. The right answer is
>> to not submit a change to the .mailmap to explicitly connect the two.
>
> While I agree with the sentiment "You are in control if your three
> names appear to refer to the same person" (and "On the Internet
> nobody knows you're a dog"), I wish the world were so black and
> white.
>
> Many people change their names over the course of their life, and
> some do not want the linkage to their past revealed.  Many of them
> have nothing to be ashamed of themselves but do so due to risk of
> discrimination, while some of them may do so to hide inconvenient
> facts about their past.  While I have no sympathy to the latter, [...]

Just on the "no sympathy for the latter" I just want to point out that
this topic is a subject of fundimental disagreement between how EU & US
legislature views this, re the recent "right to be forgotten"
developments in EU law as they relate to "directory" searches[1].

> I do not think it is unreasonable for the folks in the former camp to
> also want recognition for the achievement made under their old as
> well as their current identity.  And "pretend you have nothing to do
> with that identity you used in the past life" goes directly against
> the idea of taking credit for what you did in the past.
> [...]
> As the expertise you demonstrated under your old name will not
> help others find you as an expert in an area, until your new name
> starts being associated with your newly earned recognition, it is
> also a loss for the development community.

Indeed, I think that most people who change their name for whatever
reason on a project they contributed to before & after that change will
probably want a .mailmap entry.

I was narrowly responding to the "harassment" aspect of this. I.e. that
it's a fundimental aspect of how our object graph & git is currently
implemented that you'll be giving someone "both names" as it were.

I think that if some users want their name not to be trivially
discoverable by e.g. grepping we could cater to that & other use-cases
with something like optional URI encoding.

But I think it's equally important that we don't present something that
looks like a strong password hash to a novice user (the sha256-ing), but
which due to the party reading the data already having "both names" can
be trivially brute-forced in the time it takes to run a "git log --all
--use-mailmap", or equivalent.

I also think it's important that we keep .mailmap something where we're
explictly giving *other people* the "both names", and for ourselves &
third-party systems make it easy to use the data.

I pointed out in previous discussions how e.g. the sha-256 proposal
would require rev walking & "brute forcing" for some workflows, such as
scraping a .mailmap to insert into a relational DB, in order to make the
same association there (and I've implemented a system like this at a
past job).

I wonder to what extent concerns about the deadname use-case would be
mitigated if we added support for a .git/info/mailmap, similar to
.git/info/exclude. I.e. we now have mailmap.file, but not a way to
suppliment an in-repo .mailmap. This would help the users who want to
avoid seeing their own "deadname", but which would also like to avoid
making the association to their new name part of the public record.

1. https://en.wikipedia.org/wiki/Right_to_be_forgotten