archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <>
To: <>
Cc: "Taylor Blau" <>,
	"Ævar Arnfjörð Bjarmason" <>,
	"Emily Shaffer" <>,
	"Johannes Schindelin" <>
Subject: [RFC PATCH 0/2] Opaque author and committer identifiers
Date: Mon, 19 Sep 2022 14:52:29 +0000	[thread overview]
Message-ID: <> (raw)

There have been frequent discussions on the list about the mailmap and
how it's not currently the ideal way to map former identities to current
identities.  This is especially true for transgender people, who often
don't want to associate their deadname with their current name in plain

This is an RFC series that I talked about to some folks at Git Merge.
Roughly, this documents a format for an opaque identifier which is
compatible with existing implementations by overloading the email
address field with something that is not a real email address and cannot
be confused with one.  This opaque identifier is the fingerprint of some
key, which in most cases will be an SSH key.

It also proposes moving the mailmap out of the main history and into a
special ref for this purpose.  Notably, so as not to make the same
mistake we did with grafts, where they are not pushed by default and so
nobody uses them, the proposal here is to change tooling so that the
mailmap refs are easy to push and pull and that this is done by default
(with an easy way to opt-out).  By default, local changes to the mailmap
ref are squashed into the current commit such that there is only one
commit on the ref.  This preserves the existing mapping while not
retaining former identities, which we don't really need. (Who wants to
send email to a contributor's address at a former employer which doesn't
work anymore?)

Since this series needs a way to cart mailmap information around in
patches and I would not like to repeat the same design as base-commit,
I've proposed a separate header to include this information around.  I'm
not terribly attached to this proposal and am open to other ideas if
folks like them better, but I feel it moves us in a useful direction to
being able to include other metadata in a structured way and to sending
signed commits by patch, which other folks wanted to do (and I am in
favour of).  (I'm willing to implement such a feature based on this
approach in the future if folks desire.)

All of these changes will be optional to adopt.  Projects need not use
them if they don't want to.  However, I am proposing that they be
advertised prominently as a preferred option (for example, in the "Tell
me who you are" message) to encourage adoption.  Appropriate tooling
will be included to make this easy.

In addition, besides the general benefits for trans folks and the
ability to operate anonymously or pseudonymously, I also think using an
opaque identifier will cut down on spam.  I have received many unwelcome
solicitations from employers and survey-toting academics to my email
address, as I'm sure others have.  Receiving fewer of these in the
future will be a nice bonus.

For those folks using forges, it should be noted that associating an
identifier with an account should be very easy, since the forge usually
has SSH key support and commit verification and thus, the user's keys,
so there's no change to workflow on forges once they implement this
feature.  For those forges which use the user's personal name in the UI,
this can simply be replaced by the personal name the user has registered
with the forge.

None of this deals with rewriting identities in existing commits.  We
have what we have now and can't change it, but we can do something
different going forward.  If there is interest in the hashed mailmap
approach or another similar approach, I'm open to resurrecting that in
addition provided we agree as a project not to write tools which
trivially invert the hashed mailmap (which was the reason I dropped that
series in the first place).

I realize this is a radical departure from what we've done historically,
so this is an RFC series.  It's to gauge interest in this proposal and
design and to discuss alternatives before implementation. If we like
this approach, I will agree to implement it as my time allows, which I
expect could be done in a single series of under 30 patches.

I've CC'd some of the folks I talked to about this and some folks who I
think might be interested, but of course any constructive feedback is

brian m. carlson (2):
  doc: specify a header for including arbitrary format-patch metadata
  docs: document a format for anonymous author and committer IDs

 Documentation/technical/anonymous-id.txt      | 143 ++++++++++++++++++
 .../technical/format-patch-metadata.txt       |  58 +++++++
 2 files changed, 201 insertions(+)
 create mode 100644 Documentation/technical/anonymous-id.txt
 create mode 100644 Documentation/technical/format-patch-metadata.txt

             reply	other threads:[~2022-09-19 15:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19 14:52 brian m. carlson [this message]
2022-09-19 14:52 ` [RFC PATCH 1/2] doc: specify a header for including arbitrary format-patch metadata brian m. carlson
2022-09-19 14:52 ` [RFC PATCH 2/2] docs: document a format for anonymous author and committer IDs brian m. carlson
2022-09-20 10:51   ` Ævar Arnfjörð Bjarmason
2022-09-22  0:08     ` brian m. carlson
2022-09-30 20:26   ` Gwyneth Morgan
2022-10-02  0:27     ` 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:

* 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.
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 NNTP newsgroup(s).