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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

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, and as such I
would want to see a guarantee that we wouldn't implement or accept such
a feature.  I don't see the point of obscuring names in the mailmap if
we're just going to print them next to each other in the future, and I
don't think it's moving us towards a solution to suggest that we might
do that in the future.

I'm happy to resurrect my SHA-256 hashed mailmap series if we're
all willing to agree to not implement trivial decoding features.

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,
and using a constantly squashed mailmap commit in a special ref to store
the mapping.  This doesn't address changing identities in existing
commits, which as we've seen are nearly impossible to fix, but it does
address new ones.  I've sent it out at
https://lore.kernel.org/git/20220919145231.48245-1-sandals@crustytoothpaste.net/.

We may in fact want to do both of these things (hashed or encoded
mailmap and opaque identifiers with squashed mailmap) at once.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]