From: "brian m. carlson" <firstname.lastname@example.org>
To: Junio C Hamano <email@example.com>
Cc: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>,
"Florine W. Dekker" <email@example.com>,
"René Scharfe" <firstname.lastname@example.org>,
Subject: Re: Wildcards in mailmap to hide transgender people's deadnames
Date: Mon, 19 Sep 2022 17:26:19 +0000 [thread overview]
Message-ID: <YyimO8Vp39DWgt75@tapette.crustytoothpaste.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]
On 2022-09-19 at 16:31:25, Junio C Hamano wrote:
> "brian m. carlson" <email@example.com> writes:
> > 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
Sure. The goal is to make the tool more friendly (at least to some
folks) to use. Other people can worsen the experience; we don't have to
As I said, if we're willing to commit to not add such a decoding feature
to Git, I'm happy to resurrect my hashed mailmap approach with or
without changes and get it ready to merge. It sounds like that might be
an approach we're comfortable with here.
> > 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
Since it's not clear to me, you're saying you think a special ref is
fine, but having it be constantly squashed is not?
If so, I will say that my proposal in the other thread will let folks
keep a history if they want with a config option (although that means
you may need to rewrite history once in a while if someone changes their
name). In my workflow and in the workflow of folks who primarily work
with forges, that isn't necessary, and the mailmap, if it's even
required, can be maintained independently or even automatically. For
example, I could imagine GitHub writing my display name into the mailmap
file automatically when one of my pull requests is merged if I and the
repository owner have such an option configured.
However, in my proposed patch workflow, git am does the work for you by
updating the ref automatically, so all you need to do is literally apply
patches with mailmap headers and then push the ref once in a while.
I'm definitely open to discussing this approach more if we think it can
be formed into something viable.
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2022-09-19 17:27 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
2022-09-19 17:26 ` brian m. carlson [this message]
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] ` <CANgJU+Wt_yjv1phwiSUtLLZ=JKA9LvS=0UcBYNu+nxdJ_7d_Ew@mail.gmail.com>
2022-09-16 16:59 ` Florine W. Dekker
2022-09-20 0:32 ` brian m. carlson
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: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).