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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 19, 2022, 16:31 UTC
Message-ID: <xmqqfsgncoma.fsf@gitster.g>
In-Reply-To: <YyiIkMcADVu+Qbht@tapette.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 23 quoted lines

> On 2022-09-19 at 11:20:13, Ævar Arnfjörð Bjarmason wrote:
>> I.e. I think a "deadname" use-case of this would probably:
>> 
>> * Have some comment at the top of .mailmap about why some values are
>>   over-encoded (or perhaps it would be obvious to everyone working on
>>   that repo why someone was encoding the "plain ASCII" A-Za-z0-9 space).
>
> I don't think we need to do this.  First of all, it makes people curious
> and nosy, and it draws attention to the situation when in many cases,
> other contributors might not even notice as they're updating the
> mailmap.  Adding lots of attention is going to add the potential for
> harassment.
>
>> But should not:
>> 
>> * Assume that other tools such as "fsck", "check-mailmap" or even "log"
>>   won't have future features that make de-obscuring these values easier,
>>   or something that's part of a normal workflow.
>
> Your statement that you intended to write exactly such a feature was the
> main reason I dropped the SHA-256 hashed mailmap series.  I don't think
> it's constructive to offer or propose to offer such a feature in Git if
> we're trying to obscure people's names in the mailmap, ...

Yes, I remember that exchange, and I find your position reasonable. Yes, we all know how to build such a feature. Yes, we know a third-party implementation of such a feature may materialize.

But we do not have to be the ones to encourage use of such a feature.

> I also have an alternate proposal which I pitched to some folks at Git
> Merge and which I just finished writing up that basically moves personal
> names and emails out of commits, replacing them with opaque identifiers,

That part I can agree with.

> and using a constantly squashed mailmap commit in a special ref to store
> the mapping.

This part only half (the "special ref" half, not "constatntly squashed" part, even though I know why it matters more to your goal). My gut feeling is that auditing and merging will become nightmare.