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 text. 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 welcome. 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
