{"thread":{"id":"58457","subject":"[RFC PATCH 1/2] doc: specify a header for including arbitrary format-patch metadata","startedAt":"2022-09-19T15:00:14Z","lastAt":"2022-10-02T00:27:34Z","messageCount":7,"participants":["brian m. carlson","Ævar Arnfjörð Bjarmason","Gwyneth Morgan"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"463177","messageId":"20220919145231.48245-2-sandals@crustytoothpaste.net","threadId":"58457","inReplyTo":"20220919145231.48245-1-sandals@crustytoothpaste.net","subject":"[RFC PATCH 1/2] doc: specify a header for including arbitrary format-patch metadata","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-09-19T14:52:30Z","receivedAt":"2022-09-19T15:00:14Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Right now, we lack a way to specify arbitrary metadata for format-patch.\nWe currently special-case the base-commit value, but this is not helpful\nin the general case.  There has also been interest in specifying\nsignatures for transport between machines using mailing list patches.\n\nIn a future commit, we will define a format for the author and committer\ndata such that the email represents an opaque ID instead of an email.\nAs a practical matter, this makes it difficult to send patches, since\nmany mail servers will not accept arbitrary From lines.  Even using\nin-body From headers is not suitable here because we will want to\ninclude entries in the mailmap out-of-band as part of the patch.\n\nTo make this case more general and allow us to specify this information\nin a more general way, let's add a metadata header which can be included\nin the patch and allow specifying arbitrary values that we can then fill\nin.  We explicitly specify an extension mechanism to allow others to use\nthis data in a time-tested way that avoids conflicts.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n .../technical/format-patch-metadata.txt       | 55 +++++++++++++++++++\n 1 file changed, 55 insertions(+)\n create mode 100644 Documentation/technical/format-patch-metadata.txt\n\ndiff --git a/Documentation/technical/format-patch-metadata.txt b/Documentation/technical/format-patch-metadata.txt\nnew file mode 100644\nindex 0000000000..5448918da9\n--- /dev/null\n+++ b/Documentation/technical/format-patch-metadata.txt\n@@ -0,0 +1,55 @@\n+format-patch Metadata\n+=====================\n+\n+Background\n+----------\n+\n+The current format-patch data lacks a way to express general metadata that may\n+be useful to synthesize the original commit more accurately.  This may be\n+helpful to emit patches as a transport for actual commits between machines in a\n+case where bundles are not practical, such as a mailing list.\n+\n+Syntax\n+------\n+\n+The syntax contains three space-separated components: a field name, an encoding,\n+and field data.\n+\n+The field name contains no spaces.  Values without an `@` are specified below or\n+by a future version of Git.  Values containing an `@` followed by a domain are\n+specified by that domain owner, much as algorithm names in the SSH protocol.\n+\n+The encoding is either `plain`, in which case the field data is a literal string\n+with no spaces, or `base64`, in which case the field data is one or more\n+space-separated base64 items, which when interpreted have all spaces stripped\n+and are then encoded.  This allows fields to be specified that contain octets\n+which are not valid in or which are too long to specified in an RFC 5322 header\n+unencoded.\n+\n+Fields\n+------\n+\n+base-commit-sha1::\n+\tThis specifies the base commit for this patch using a SHA-1 object ID.\n+base-commit-sha256::\n+\tThis specifies the base commit for this patch using a SHA-256 object ID.\n+\tappropriate.\n+gpgsig-sha1::\n+\tThis specifies a signature for this patch using the SHA-1 format, as specified\n+\tin the `gpgsig` header.\n+gpgsig-sha256::\n+\tThis specifies the base commit for this patch using the SHA-256 object ID, as\n+\tspecified in the `gpgsig-sha256` header.\n+\n+Examples\n+--------\n+\n+----\n+X-Git-Metadata: base-commit-sha1 plain da39a3ee5e6b4b0d3255bfef95601890afd80709\n+\n+X-Git-Metadata: gpgsig-sha256 base64\n+  LS0tLS1CRUdJTiBTU0ggU0lHTkFUVVJFLS0tLS0KYmxhaCBibGFoIGJsYWgKLS0tLS1FTkQgU1NI\n+  IFNJR05BVFVSRS0tLS0tCg==\n+\n+X-Git-Metadata: foo@example.com plain quux\n+----\n"},{"id":"463178","messageId":"20220919145231.48245-1-sandals@crustytoothpaste.net","threadId":"58457","inReplyTo":null,"subject":"[RFC PATCH 0/2] Opaque author and committer identifiers","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-09-19T14:52:29Z","receivedAt":"2022-09-19T15:00:17Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"There have been frequent discussions on the list about the mailmap and\nhow it's not currently the ideal way to map former identities to current\nidentities.  This is especially true for transgender people, who often\ndon't want to associate their deadname with their current name in plain\ntext.\n\nThis is an RFC series that I talked about to some folks at Git Merge.\nRoughly, this documents a format for an opaque identifier which is\ncompatible with existing implementations by overloading the email\naddress field with something that is not a real email address and cannot\nbe confused with one.  This opaque identifier is the fingerprint of some\nkey, which in most cases will be an SSH key.\n\nIt also proposes moving the mailmap out of the main history and into a\nspecial ref for this purpose.  Notably, so as not to make the same\nmistake we did with grafts, where they are not pushed by default and so\nnobody uses them, the proposal here is to change tooling so that the\nmailmap refs are easy to push and pull and that this is done by default\n(with an easy way to opt-out).  By default, local changes to the mailmap\nref are squashed into the current commit such that there is only one\ncommit on the ref.  This preserves the existing mapping while not\nretaining former identities, which we don't really need. (Who wants to\nsend email to a contributor's address at a former employer which doesn't\nwork anymore?)\n\nSince this series needs a way to cart mailmap information around in\npatches and I would not like to repeat the same design as base-commit,\nI've proposed a separate header to include this information around.  I'm\nnot terribly attached to this proposal and am open to other ideas if\nfolks like them better, but I feel it moves us in a useful direction to\nbeing able to include other metadata in a structured way and to sending\nsigned commits by patch, which other folks wanted to do (and I am in\nfavour of).  (I'm willing to implement such a feature based on this\napproach in the future if folks desire.)\n\nAll of these changes will be optional to adopt.  Projects need not use\nthem if they don't want to.  However, I am proposing that they be\nadvertised prominently as a preferred option (for example, in the \"Tell\nme who you are\" message) to encourage adoption.  Appropriate tooling\nwill be included to make this easy.\n\nIn addition, besides the general benefits for trans folks and the\nability to operate anonymously or pseudonymously, I also think using an\nopaque identifier will cut down on spam.  I have received many unwelcome\nsolicitations from employers and survey-toting academics to my email\naddress, as I'm sure others have.  Receiving fewer of these in the\nfuture will be a nice bonus.\n\nFor those folks using forges, it should be noted that associating an\nidentifier with an account should be very easy, since the forge usually\nhas SSH key support and commit verification and thus, the user's keys,\nso there's no change to workflow on forges once they implement this\nfeature.  For those forges which use the user's personal name in the UI,\nthis can simply be replaced by the personal name the user has registered\nwith the forge.\n\nNone of this deals with rewriting identities in existing commits.  We\nhave what we have now and can't change it, but we can do something\ndifferent going forward.  If there is interest in the hashed mailmap\napproach or another similar approach, I'm open to resurrecting that in\naddition provided we agree as a project not to write tools which\ntrivially invert the hashed mailmap (which was the reason I dropped that\nseries in the first place).\n\nI realize this is a radical departure from what we've done historically,\nso this is an RFC series.  It's to gauge interest in this proposal and\ndesign and to discuss alternatives before implementation. If we like\nthis approach, I will agree to implement it as my time allows, which I\nexpect could be done in a single series of under 30 patches.\n\nI've CC'd some of the folks I talked to about this and some folks who I\nthink might be interested, but of course any constructive feedback is\nwelcome.\n\nbrian m. carlson (2):\n  doc: specify a header for including arbitrary format-patch metadata\n  docs: document a format for anonymous author and committer IDs\n\n Documentation/technical/anonymous-id.txt      | 143 ++++++++++++++++++\n .../technical/format-patch-metadata.txt       |  58 +++++++\n 2 files changed, 201 insertions(+)\n create mode 100644 Documentation/technical/anonymous-id.txt\n create mode 100644 Documentation/technical/format-patch-metadata.txt\n\n"},{"id":"463179","messageId":"20220919145231.48245-3-sandals@crustytoothpaste.net","threadId":"58457","inReplyTo":"20220919145231.48245-1-sandals@crustytoothpaste.net","subject":"[RFC PATCH 2/2] docs: document a format for anonymous author and committer IDs","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-09-19T14:52:31Z","receivedAt":"2022-09-19T15:00:25Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The original design of Git embeds a personal name and email in every\ncommit.  This has lots of downsides, including the following.\n\nFirst, people do not want to bake an email into an immutable Merkle tree\nthat they send everywhere.  Spam, whether in general or by recruiters,\nis a problem, and even when it's not, people change companies or\ninstitutions and emails become invalid.\n\nSecond, some people prefer to operate anonymously and don't want to\nspecify personal details everywhere.\n\nThird, and most important, people change names.  This happens for many\nreasons, but it comes up most saliently for transgender people, who\nfrequently change their name as part of their transition.  Referring to\na transgender person's former name, their \"deadname\", is considered\ninappropriate.\n\nWe have a solution that can map former personal names and emails into\ncurrent ones, the mailmap.  However, this last case poses a problem,\nbecause we don't really want to correlate the person's deadname (or\ntheir email, which may contain their deadname) right next to their\ncurrent name.\n\nSeveral solutions have been proposed for this case, including hashing or\nencoding the old information, but these are all easily invertible.\nInstead, let's propose a new form of identifier which is opaque and some\nmailmap improvements to store the mailmap information outside of the\nmain history.\n\nPropose that users use the fingerprint of a cryptographic key as part of\na special-form email which is not valid according to RFC 1123, but is\naccepted by earlier versions of Git.  Now that we have SSH signing and\nOpenSSH is available on all major platforms, creating a unique ID is as\neasy as running ssh-keygen.  This approach results in an identifier\nwhich is unique, deterministic, and completely anonymous.\n\nPropose this new option instead of using a name and email, although\nusers can continue to use those as before if they prefer. Continue to\nassociate personal information with this opaque identifier using the\nmailmap, but in such a way that it lives in a special ref outside of the\nhistory and that ref is customarily kept squashed to a single commit.\nCreate a special RFC 5322 header to associate a mailmap entry with the\nuser's opaque identifier when sending a patch if desired.\n\nBecause the mailmap now lives outside the history in a single squashed\ncommit, a user may simply update their name by sending a new patch with\nthe same opaque ID, or proposing a change to the mailmap independently.\nA person's former name or email address is not retained in the history\n(unless the project chooses to do that for the mailmap ref).\n\nSince many people use forges for hosting their code and forges offer\ncommit verification and SSH access, it is extremely easy for a forge to\nassociate a commit with this new opaque identifier with a user, since\nthey probably already have this information.  Thus, for projects which\nuse solely a forge-based development workflow, no mailmap entry need\neven be created unless one is desired.  If one is desired, it may be\nable to be created and updated automatically as part of the forge's\nnormal infrastructure simply upon sending a patch.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n Documentation/technical/anonymous-id.txt      | 143 ++++++++++++++++++\n .../technical/format-patch-metadata.txt       |   3 +\n 2 files changed, 146 insertions(+)\n create mode 100644 Documentation/technical/anonymous-id.txt\n\ndiff --git a/Documentation/technical/anonymous-id.txt b/Documentation/technical/anonymous-id.txt\nnew file mode 100644\nindex 0000000000..aeba5e68f2\n--- /dev/null\n+++ b/Documentation/technical/anonymous-id.txt\n@@ -0,0 +1,143 @@\n+Anonymous IDs\n+=============\n+\n+Objective\n+---------\n+\n+Provide a way for people to identify themselves without the need to associate a\n+fixed personal name or email.\n+\n+Background\n+----------\n+\n+People change their name and email many times over the course over their lives.\n+For example, people may marry or change jobs.  In many cases, these changes can\n+be handled by the mailmap.  However, for many transgender people, keeping the\n+old name in the mailmap is often undesirable.\n+\n+This document proposes a new way to specify anonymous IDs based on an SSH key or\n+GnuPG key instead along with a mailmap which is automatically downloaded from\n+the remote which provides an automatic correspondence.  In this approach, all\n+users are expected to specify an anonymous ID and a mailmap entry.\n+\n+This does not solve the problem of previous commits, but it does solve the\n+approach going forward if reasonably well adopted and avoids the problems of\n+existing approaches of obscuring the mailmap which are defeated by simply\n+enumerating all entries in all commits.\n+\n+Anonymous IDs\n+-------------\n+\n+Git will implement a new form of email address which is acceptable to existing\n+implementations but is not valid according to RFC 1123.  This takes the form of\n+an email address where the local-part contains the identifier and the domain\n+portion starts with `_.` and then a domain specifier which specifies an\n+authority and the meaning of the identifier.\n+\n+In such a case, Git will specify the username as a single U+2060 in UTF-8 (the\n+byte sequence 0xE2 0x81 0xA0), which is a zero width non-breaking space.  This\n+is compatible with existing implementations.\n+\n+The Git project will specify a set of identifiers under the domain\n+`id.git-scm.com`.  The next component is the type of key as specified by the\n+`gpg.program` identifier, and then a component indicating the hash type or\n+version number as specified below.\n+\n+This approach provides IDs which are simple and easy to create (almost all users\n+will have an SSH implementation which can generate keys with a single command),\n+opaque, completely deterministic, and not personally identifiable.\n+\n+Other authorities, such as hosting providers, may use different IDs.  For\n+example, if the hosting provider example.com might issue the ID\n+`1234@_.user.example.com` for user ID 1234.  Authorities are encouraged to use\n+database IDs or other unique IDs rather than usernames, since many usernames\n+contain human names or corporate affiliations, which defeats the point of this\n+feature.\n+\n+In conjunction with a single, constantly rewritten mailmap reference and\n+`mailmap.blob`, this allows users to move their real IDs outside of the commit\n+IDs into a mailmap which is constantly rewritten.  If a user's real name or\n+email changes, they can submit an update to the mailmap and the ID, which will\n+be squashed into a single commit without history.\n+\n+Specifications\n+~~~~~~~~~~~~~~\n+\n+OpenPGP Keys\n+^^^^^^^^^^^^\n+\n+If a user possesses a v4 OpenPGP key, then they may use the domain\n+`_.v4.openpgp.id.git-scm.com` using a lowercase hex form of the SHA-1\n+fingerprint as the local-part.  For example, the key with the fingerprint\n+`da39a3ee5e6b4b0d3255bfef95601890afd80709` would have the email address\n+`da39a3ee5e6b4b0d3255bfef95601890afd80709@_v4.openpgp.id.git-scm.com`.\n+\n+Similarly, when RFC 4880 bis is implemented using v5 keys with SHA-256\n+fingerprints, the domain `_.v5.openpgp.id.git-scm.com` may be used with a\n+lowercase hex form of the SHA-256 fingerprint as the local-part.\n+\n+SSH Keys\n+^^^^^^^^\n+\n+If a user possesses an SSH key, then they may use the domain\n+`_.sha256.ssh.id.git-scm.com` using a base64url encoding (without padding) as\n+the local-part.  This is the RFC 4648 Base64 encoding with URL and filename safe\n+alphabet without the padding character.  For example, a user whose SSH key\n+fingerprint is `47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU` may use\n+`47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU@_.sha256.ssh.id.git-scm.com`.\n+\n+It's intentional that no specification is provided for MD5 fingerprints.  MD5 is\n+obsolete and should not be used in new protocols such as this.\n+\n+X.509 Certificates\n+^^^^^^^^^^^^^^^^^^\n+\n+If a user possesses an X.509 certificate, then they may use the domain\n+`_.sha256.x509.id.git-scm.com` using a lowercase hex form of the SHA-256\n+fingerpint of the certificate.  For example, if the key fingerprint is\n+`e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`, then the ID\n+would be\n+`e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855@_.sha256.x509.id.git-scm.com`.\n+\n+Emission\n+~~~~~~~~\n+\n+A user may specify, instead of `user.email`, a `user.signingkey` (or a suitable\n+protocol-specific setting).  If `user.idFormat` is set to `email`, then the\n+user's email will be written into the commit; if it is instead set to `key`,\n+then the ID corresponding to the key is extracted from the signing program and\n+that is used instead.  `id` can be used to specify the `user.id` value. An order\n+of items to try can be specifed with a colon-separated list.  The default, which\n+is subject to change, is `id:email:key`.  This allows users to specify an\n+independent ID which is independent of their email.\n+\n+For patches, a user may specify `format.id` as `as-is` to leave the data as is,\n+or as `mailmap` to use the mailmap value to rewrite it to the value in the\n+mailmap. If the user specifies `mailmap-metadata`, then an in-body `From:` line\n+in the patch is written to contain the author ID using the ID as written in the\n+commit, but a format-patch metadata header is written using the mailmap entry in\n+the commit.\n+\n+Expected Mailmap Improvements\n+-----------------------------\n+\n+Right now, the mailmap is included in a repository as part of a regular commit.\n+This means it has a history, which is undesirable if the user would like to\n+completely rewrite their identity.\n+\n+This can be easily solved with some mailmap improvements.  `git clone` will\n+learn a command, `--use-mailmap`, which will specifically fetch the ref\n+`refs/mailmap` from the remote and keep it up to date using force updates if\n+necessary.  This option will also specify `mailmap.blob` to point to the\n+`.mailmap` file in this ref, which allows the user to automatically keep it up\n+to date with the remote.\n+\n+`git am` or `git apply` can then apply the mailmap entry from the patch to the\n+appropriate ref with `--use-mailmap`.  The default is `--use-mailmap=amend`,\n+which amends the existing commit.   If a user would like to preserve a history\n+for some reason, they can use `--use-mailmap=commit`.  For maintainers, they can\n+then push this ref using the normal push refspecs, or explicitly with\n+`--mailmap`, which is equivalent to `+refs/mailmap:refs/mailmap`.\n+\n+The goal of this is to make interacting with the mailmap refs automatic and\n+transparent whenever other data is fetched or cloned from the remote.\ndiff --git a/Documentation/technical/format-patch-metadata.txt b/Documentation/technical/format-patch-metadata.txt\nindex 5448918da9..87e301b65e 100644\n--- a/Documentation/technical/format-patch-metadata.txt\n+++ b/Documentation/technical/format-patch-metadata.txt\n@@ -40,6 +40,9 @@ gpgsig-sha1::\n gpgsig-sha256::\n \tThis specifies the base commit for this patch using the SHA-256 object ID, as\n \tspecified in the `gpgsig-sha256` header.\n+mailmap-author::\n+\tThis specifies the mailmap entry to associate with the email address or other\n+\tidentifier in the `From:` header.\n \n Examples\n --------\n"},{"id":"463298","messageId":"220920.86a66u5mnt.gmgdl@evledraar.gmail.com","threadId":"58457","inReplyTo":"20220919145231.48245-3-sandals@crustytoothpaste.net","subject":"Re: [RFC PATCH 2/2] docs: document a format for anonymous author and committer IDs","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-20T10:51:39Z","receivedAt":"2022-09-20T11:07:58Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Sep 19 2022, brian m. carlson wrote:\n\n> The original design of Git embeds a personal name and email in every\n> commit.  This has lots of downsides, including the following.\n>\n> First, people do not want to bake an email into an immutable Merkle tree\n> that they send everywhere.  Spam, whether in general or by recruiters,\n> is a problem, and even when it's not, people change companies or\n> institutions and emails become invalid.\n>\n> Second, some people prefer to operate anonymously and don't want to\n> specify personal details everywhere.\n>\n> Third, and most important, people change names.  This happens for many\n> reasons, but it comes up most saliently for transgender people, who\n> frequently change their name as part of their transition.  Referring to\n> a transgender person's former name, their \"deadname\", is considered\n> inappropriate.\n>\n> We have a solution that can map former personal names and emails into\n> current ones, the mailmap.  However, this last case poses a problem,\n> because we don't really want to correlate the person's deadname (or\n> their email, which may contain their deadname) right next to their\n> current name.\n>\n> Several solutions have been proposed for this case, including hashing or\n> encoding the old information, but these are all easily invertible.\n> Instead, let's propose a new form of identifier which is opaque and some\n> mailmap improvements to store the mailmap information outside of the\n> main history.\n\nWith you so far...\n\n> Propose that users use the fingerprint of a cryptographic key as part of\n> a special-form email which is not valid according to RFC 1123, but is\n> accepted by earlier versions of Git.  Now that we have SSH signing and\n> OpenSSH is available on all major platforms, creating a unique ID is as\n> easy as running ssh-keygen.  This approach results in an identifier\n> which is unique, deterministic, and completely anonymous.\n\n...but...\n\n> Propose this new option instead of using a name and email, although\n> users can continue to use those as before if they prefer. Continue to\n> associate personal information with this opaque identifier using the\n> mailmap, but in such a way that it lives in a special ref outside of the\n> history and that ref is customarily kept squashed to a single commit.\n> Create a special RFC 5322 header to associate a mailmap entry with the\n> user's opaque identifier when sending a patch if desired.\n\n...while it's technically neat, I really don't see why this whole\nhashing mechanism is a necessary prerequisite to get to this point.\n\nWouldn't we get the same thing if *by convention* we just supported\nauthorship like this, (which we already support):\n\n\tUUID=$(get-some-uuid)\n        git config user.name X\n        git config user.email $UUID.uuid.git.example.org\n\nSo you'd end up with e.g.:\n\n\tX <98ab8d66-38d2-11ed-a261-0242ac120002.uuid.git.example.com>\n\nOr whatever, we could bikeshed about the format, but the point is that\nit's not codifying *how* that looks.\n\nWe'd then just support this refs/mailmap mechanism you're suggesting,\nwhere we'd have a mapping like:\n\n      Ævar Arnfjörð Bjarmason <avarab@gmail.com> X <98ab8d66-38d2-11ed-a261-0242ac120002.uuid.git.example.com>\n\nWhich could be force-pushed.\n\nI can see why you'd *also* want to formalize the ID generation, but I\njust don't see why we'd want to make that as one leaping change rather\nthan something more incremental.\n\nI.e. even if you don't have opaque IDs in the first place this mechanism\nwould allow you to maintain a \"mailmap\" ref on the remote, which would\nalready be useful.\n\nE.g. now if I use a hosting provider and have my .mailmap in various\nrepo I need to maintain then in each repo, but this would allow for a\nmagical ref which would keep it up-to-date in various repos...\n\n> [...]If a user would like to preserve a history\n> +for some reason, they can use `--use-mailmap=commit`.  For maintainers, they can\n> +then push this ref using the normal push refspecs, or explicitly with\n> +`--mailmap`, which is equivalent to `+refs/mailmap:refs/mailmap`.\n\nI obviously see why you want the \"force push\" aspect of this (the\ndeadnaming), but I still wonder if it's really a good trade-off for git\nas an SCM to make that the default.\n\nWe've been going in the other direction for e.g. tags semi-recently with\nmy 0bc8d71b99e (fetch: stop clobbering existing tags without --force,\n2018-08-31).\n\nBy having that force-push default we make it so that a plumbing command\n(that makes use of mailmap) will give you one result today, but a\ndifferent one tomorrow, with no easy way to get back.\n\nMaybe it's something we want in the end, but it's another thing that's\n\"changed while at it\", i.e. not only are we introducing \"mailmap\" remote\nrefs, but also:\n\n * Changing the many-to-many mapping of history-mailmap to a\n   many-to-one, i.e. the map is per-repo, not per-ref.\n\n * Changing it so that you can't track is as part of your history.\n\nIf we wanted to ease into just one of those we could have a \"mailmap\"\ntag object, which we wouldn't clobber by default....\n\n"},{"id":"463409","messageId":"Yyune8ZNhWGWaTf2@tapette.crustytoothpaste.net","threadId":"58457","inReplyTo":"220920.86a66u5mnt.gmgdl@evledraar.gmail.com","subject":"Re: [RFC PATCH 2/2] docs: document a format for anonymous author and committer IDs","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-09-22T00:08:27Z","receivedAt":"2022-09-22T00:08:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-09-20 at 10:51:39, Ævar Arnfjörð Bjarmason wrote:\n> Wouldn't we get the same thing if *by convention* we just supported\n> authorship like this, (which we already support):\n> \n> \tUUID=$(get-some-uuid)\n>         git config user.name X\n>         git config user.email $UUID.uuid.git.example.org\n\nYou can indeed use a UUID if you want.  However, it's not deterministic.\n\nUsing a key hash also means account linking is trivially implemented in\nforges.  If we use a UUID, then there's no way to prove ownership of the\nidentifier, which means that people can claim other people's commits.\nSigned commits don't help here because you can't embed arbitrary\nnon-emails in X.509 (or in OpenPGP, because nobody will certify such an\nID), so you have no way of linking the commit identity to the key and\ntherefore signed commits are worse than before.  At least with an email\nyou can verify that the owner of the account owns the email address, but\nyou can't do that with a UUID.\n\nI want a design that works whether or not you use a forge, but realizing\nthat most developers use forges these days, I want to make the workflow as\nsimple and straightforward as possible for those who do.  I also want a\ndesign which is going to be acceptable to forge implementers, and\nworking for one, I think this design is going to be easier to implement\nand more likely to be accepted than an ID which requires extra work and\nisn't verifiable.\n\nFor ease of use, I would be implementing tooling to make setting this\nfrom an existing user.signingkey or SSH key on the system.  I literally\nenvision this being as simple as something like `git id --set -f\n~/.ssh/id_ed25519` or `git id --set --generate-ssh-key`.  (This is just\nan example; we can argue about the details later.)\n\n> So you'd end up with e.g.:\n> \n> \tX <98ab8d66-38d2-11ed-a261-0242ac120002.uuid.git.example.com>\n> \n> Or whatever, we could bikeshed about the format, but the point is that\n> it's not codifying *how* that looks.\n\nI do very much want to codify how this looks because people are\nabsolutely going to rely on it, whether we want them to or not.  People\nalready parse GitHub's fake no-reply emails for information.  Everything\nthat Git does people rely on, whether we like it or not.\n\nKeeping it in the form of an email maximizes compatibility for existing\nimplementations.\n\n> We'd then just support this refs/mailmap mechanism you're suggesting,\n> where we'd have a mapping like:\n> \n>       Ævar Arnfjörð Bjarmason <avarab@gmail.com> X <98ab8d66-38d2-11ed-a261-0242ac120002.uuid.git.example.com>\n> \n> Which could be force-pushed.\n> \n> I can see why you'd *also* want to formalize the ID generation, but I\n> just don't see why we'd want to make that as one leaping change rather\n> than something more incremental.\n\nWe can make it as incremental as folks want.  However, the longer we\nhave people embedding their real names and emails in an immutable Merkle\ntree, the longer we're going to run into deadname problems.  Thus,\nencouraging this new form of ID sooner means that people will adopt it\nsooner.\n\nIf this is the only impediment, we can make it more gradual.\n\n> I.e. even if you don't have opaque IDs in the first place this mechanism\n> would allow you to maintain a \"mailmap\" ref on the remote, which would\n> already be useful.\n> \n> E.g. now if I use a hosting provider and have my .mailmap in various\n> repo I need to maintain then in each repo, but this would allow for a\n> magical ref which would keep it up-to-date in various repos...\n\nThat's part of the goal.\n\n> I obviously see why you want the \"force push\" aspect of this (the\n> deadnaming), but I still wonder if it's really a good trade-off for git\n> as an SCM to make that the default.\n> \n> We've been going in the other direction for e.g. tags semi-recently with\n> my 0bc8d71b99e (fetch: stop clobbering existing tags without --force,\n> 2018-08-31).\n> \n> By having that force-push default we make it so that a plumbing command\n> (that makes use of mailmap) will give you one result today, but a\n> different one tomorrow, with no easy way to get back.\n\nI think force-pushing semantics has a nicer behaviour for my use case,\nbut it's not essential.  If the mailmap is in a separate ref, then if I\nwork at $MEGACORP and need to update the mailmap because of a name\nchange, I can still just rewrite the history, and as long as we preserve\nthe force-fetch behaviour by default, then it will just work.\n\nI _do_ think we should retain the force-fetch behaviour by default.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"464012","messageId":"YzdQwNCtwAYjhKWp@tilde.club","threadId":"58457","inReplyTo":"20220919145231.48245-3-sandals@crustytoothpaste.net","subject":"Re: [RFC PATCH 2/2] docs: document a format for anonymous author and committer IDs","fromName":"Gwyneth Morgan","fromEmail":"gwymor@tilde.club","sentAt":"2022-09-30T20:26:41Z","receivedAt":"2022-09-30T20:35:01Z","isPatch":true,"sender":{"key":"gwymor@tilde.club","avatar":"https://avatars.githubusercontent.com/u/87623694?v=4"},"body":"In general, I like this proposal. It seems like a good way forward.\n\nIt should be made very clear to the user that a commit authored by a\nkey-derived ID does not imply the commit is signed by that key or\nprovide any security guarantees; anyone can put anything in that field,\nsame as it is now. I could see someone seeing a commit authored by\n<47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU@_.sha256.ssh.id.git-scm.com>\nand thinking that implies the commit was signed by\n`47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU`.\n\nOn 2022-09-19 14:52:31+0000, brian m. carlson wrote:\n> +Anonymous IDs\n> +-------------\n> +\n> +Git will implement a new form of email address which is acceptable to existing\n> +implementations but is not valid according to RFC 1123.  This takes the form of\n> +an email address where the local-part contains the identifier and the domain\n> +portion starts with `_.` and then a domain specifier which specifies an\n> +authority and the meaning of the identifier.\n> +\n> +In such a case, Git will specify the username as a single U+2060 in UTF-8 (the\n> +byte sequence 0xE2 0x81 0xA0), which is a zero width non-breaking space.  This\n> +is compatible with existing implementations.\n\nCould you add a note here explaining why that character was chosen for\nthe name field? It seems like it would be easier to work with a single\nprintable character like `?` or `X`, but maybe that doesn't matter here.\n"},{"id":"464050","messageId":"Yzja6eSq15Q1a8Rs@tapette.crustytoothpaste.net","threadId":"58457","inReplyTo":"YzdQwNCtwAYjhKWp@tilde.club","subject":"Re: [RFC PATCH 2/2] docs: document a format for anonymous author and committer IDs","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-10-02T00:27:21Z","receivedAt":"2022-10-02T00:27:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-09-30 at 20:26:41, Gwyneth Morgan wrote:\n> In general, I like this proposal. It seems like a good way forward.\n> \n> It should be made very clear to the user that a commit authored by a\n> key-derived ID does not imply the commit is signed by that key or\n> provide any security guarantees; anyone can put anything in that field,\n> same as it is now. I could see someone seeing a commit authored by\n> <47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU@_.sha256.ssh.id.git-scm.com>\n> and thinking that implies the commit was signed by\n> `47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU`.\n\nOf course.  I'll update that when I turn this into a real series.\n\n> On 2022-09-19 14:52:31+0000, brian m. carlson wrote:\n> > +Anonymous IDs\n> > +-------------\n> > +\n> > +Git will implement a new form of email address which is acceptable to existing\n> > +implementations but is not valid according to RFC 1123.  This takes the form of\n> > +an email address where the local-part contains the identifier and the domain\n> > +portion starts with `_.` and then a domain specifier which specifies an\n> > +authority and the meaning of the identifier.\n> > +\n> > +In such a case, Git will specify the username as a single U+2060 in UTF-8 (the\n> > +byte sequence 0xE2 0x81 0xA0), which is a zero width non-breaking space.  This\n> > +is compatible with existing implementations.\n> \n> Could you add a note here explaining why that character was chosen for\n> the name field? It seems like it would be easier to work with a single\n> printable character like `?` or `X`, but maybe that doesn't matter here.\n\nSure, I'll include that there.  The author field cannot be empty for\ncompatibility reasons.  Since there's nothing to put there until it's\nrun through the mailmap, putting a single zero-width non-breaking space\nproduces the same rendering as nothing, and it doesn't require special\nhandling like \"?\" or \"X\". (Also, it should be noted that not all\nlanguages use \"?\" as the question mark.)\n\nNote that if this is mapped in the mailmap, you don't need to actually\nput the personal name that exists in the commit.  The mailmap rewrites\nbased on the email address (or, in this case, the ID), so nobody ever\nhas to write the U+2060 in the mailmap.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"}]}