mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: "brian m. carlson" <>
Cc: "Ævar Arnfjörð Bjarmason" <>,
	"Florine W. Dekker" <>,
	"René Scharfe" <>,
Subject: Re: Wildcards in mailmap to hide transgender people's deadnames
Date: Mon, 19 Sep 2022 09:31:25 -0700	[thread overview]
Message-ID: <xmqqfsgncoma.fsf@gitster.g> (raw)
In-Reply-To: <> (brian m. carlson's message of "Mon, 19 Sep 2022 15:19:44 +0000")

"brian m. carlson" <> writes:

> 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

> 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

  reply	other threads:[~2022-09-19 16:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13 21:53 Wildcards in mailmap to hide transgender people's deadnames Florine W. Dekker
2022-09-14  7:40 ` René Scharfe
2022-09-14  9:07   ` Florine W. Dekker
2022-09-19 11:20     ` Ævar Arnfjörð Bjarmason
2022-09-19 12:27       ` rsbecker
2022-09-19 15:19       ` brian m. carlson
2022-09-19 16:31         ` Junio C Hamano [this message]
2022-09-19 17:26           ` brian m. carlson
2022-09-20 10:23         ` Ævar Arnfjörð Bjarmason
2022-09-20 14:58           ` Florine W. Dekker
2022-09-21 16:42           ` Junio C Hamano
2022-09-26  9:14             ` Ævar Arnfjörð Bjarmason
     [not found]   ` <>
2022-09-16 16:59     ` Florine W. Dekker
2022-09-20  0:32       ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqfsgncoma.fsf@gitster.g \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).