{"thread":{"id":"59540","subject":"Improving support for name changes in git","startedAt":"2023-04-04T18:00:08Z","lastAt":"2023-04-26T18:43:18Z","messageCount":3,"participants":["Bran Hagger","Junio C Hamano","Gwyneth Morgan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"474792","messageId":"LV2PR21MB31334981E02BCA25792BAFFCCF939@LV2PR21MB3133.namprd21.prod.outlook.com","threadId":"59540","inReplyTo":null,"subject":"Improving support for name changes in git","fromName":"Bran Hagger","fromEmail":"brhagger@microsoft.com","sentAt":"2023-04-04T18:00:00Z","receivedAt":"2023-04-04T18:00:08Z","isPatch":false,"sender":{"key":"brhagger@microsoft.com","avatar":null},"body":"Hello Git community,\n\nI'm interested in volunteering to help improve the process for users changing their name in Git.\n\nI've seen the notes from the Git summit[1] and the old proposal to change the .mailmap to use hashes instead of plaintext names[2]. The problem with both approaches is that it is easy for other users to figure out the old name, which is a privacy concern for many people who change their names. Since the reverse of the hashes in the second case can be easily brute-forced, using hashes in the .mailmap provides no additional protection.\n\nA system that prevents people from reverse-engineering the old name of a user who changes their name would require two key components:\n\n1. The method of determining the current name of the author of a git commit can not rely on any information derived from their old name.\n2. The mapping to the current name of the author of a git commit can not contain any history.\n\nSolving the first problem seems reasonably doable. Instead of each commit having an author name and email, the author section could contain a hash that is used for the mapping. To maintain compatibility with older versions of git, the format could look something like:\nAuthor: Hash #user.idHash <email@lookIn.newMailmap>​\nWith the user.idHash is a randomly generated number set in the .gitconfig the same way user.name and user.email currently are. A .newMailmap file (or whatever name we choose to give it) would then map from user id hashes to user names and emails.\n\nThe second problem of how to maintain a mapping of user.idHash without history is a radical departure from how git currently works. While handling such a file on the client side is probably not too technically complicated, it raises several questions:\n\n* How can a git repository accept changes and protect against malicious actors modifying the .newMailmap file (or however we choose to name it)? Making pull requests to modify the file and keeping those pull requests around recreates the old issue of having a record of every name change.\n* How are merge conflicts handled?\n* How do we ensure users can only set the name and email for their own hashes? If the commits are signed this could be done via signing verification, but my understanding is that signing commits is relatively rare.\n\nHas there been any further work done on supporting git name changes that I missed? Are there any existing files without git history that face similar issues?\n\n[1] https://code.googlesource.com/git/summit/2020/+/main/notes.md\n[2] https://lore.kernel.org/git/20210103211849.2691287-1-sandals@crustytoothpaste.net/\n\nThank you,\nBran (he/him)\n\nP.S. Apologies for potentially double-sending this. My email client accidentally added HTML to the first copy."},{"id":"474897","messageId":"xmqqcz4hrct0.fsf@gitster.g","threadId":"59540","inReplyTo":"LV2PR21MB31334981E02BCA25792BAFFCCF939@LV2PR21MB3133.namprd21.prod.outlook.com","subject":"Re: Improving support for name changes in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-06T01:59:07Z","receivedAt":"2023-04-06T01:59:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bran Hagger <brhagger@microsoft.com> writes:\n\n> I'm interested in volunteering to help improve the process for\n> users changing their name in Git.\n\nTo \"improve\", we need to understand what these users want when they\nchange their names.  Changing the names and changing the e-mail\naddresses are both commonly done, and people depending on\ncircumstances want different things from the tool.  Some do not want\nto be known that the person who used to use that old name is you,\nthe person who uses this new name.  Some do not mind their old name\nor address to be in the record but they want to take credit for what\nthey did under both names.  There may be some position in between,\nwith various degrees of being realistic (e.g. \"I do not want to be\nassociated with the old commit, but at the same time I do want to\ntake credit for it\"---is that a reasonable desire?).\n\n> Solving the first problem seems reasonably doable....\n\nUp to this point, I found what you wrote to be reasoned very nicely.\nHowever, ...\n\n> The second problem of how to maintain a mapping of user.idHash\n> without history is a radical departure from how git currently\n> works.\n\n... I think the above is an understatement.  No \"radical departure\"\nwould change the fundamental issue here: people need to be able to\nmap the random token X to the \"current name\" right now, and the\nmechanism used to do so can be replayed at later date because a\nmapping will be distributed, copied and saved.  Or a much simpler\nand obvious source of the problem is that people have memories.\n\nPeople change names and addresses over the course of their lives.\nEmployers may encourage their employees to use their corporate ident\nwhen contributing to an external project, and often their employment\ncontract would make it clear that rights to the work belong to the\nemployers.  When employees move on, old contributions need to stay\nto be \"owned\" by the original user ident.\n\n\tSide note: when changing an employer, people may more often\n\tchange the address but not names.  But technically names and\n\taddresses as part of author/committer ident have the same\n\tcharacteristics in Git (e.g. being part of a etched-in-stone\n\tidentity string), and the address is much less loaded\n\temotionally, I'll talk about address change in this\n\tparagraph, but the same discussion applies to name change.\n\nSome of these employees may not mind letting others know that the\nperson who made these old contributions and the person who is making\nnew contributions under different name and/or address are the same\nperson.  Others may be ashamed of their past association to the $EVIL\ncompany and may want to start afresh, without being known about their\npast employment with them.\n\nThe mailmap mechanism is a great way for the former group of folks.\nIt allows them to group the contributions by such a person who had\nmultiple idents over time into a single bucket.  But the mechanism\nmay not be suited for other uses, including the latter.\n\nSome folks, after changing their name and/or address, do not want it\nto be known that they used to use that name and/or address (e.g.\nthey may be a victim of a crime, being stalked, etc.)  The mailmap\nmechanism would not help, even with your \"random token\" redirection,\nand it shouldn't, because for those folks, they do not want to be\nassociated with their old ident after they started using new one.\nThe idea to use mailmap to somehow \"link\" the author of these old\ncommits (made under old ident) and the author of the new commits\n(made under new ident of the same physical person who wants the\nassociation with the old ident not to be known) _creates_ the\nproblem of \"the linkage between two idents, which was made with\nclever use of random token to make it irreversible, can be\nrecovered\".\n\nIf \"Such and such person used to work at $CORP and made these\ncontribution\" was publically known as a fact before the person\nchanged their name and/or address, it is impossible to force all\nother people to forget.  Wouldn't the only practical solution be to\nstick to your new ident, and not talk about the old ident you used\nto use?  If you try to abuse mailmap for something it wasn't even\ndesigned to and have any entry to link the old and new ident in some\nway, isn't it backwards as a solution, when what you want is that\nthe linkage between the old ident and you not to be known?\n"},{"id":"476130","messageId":"ZElux+kFcskXVL9Y@tilde.club","threadId":"59540","inReplyTo":"LV2PR21MB31334981E02BCA25792BAFFCCF939@LV2PR21MB3133.namprd21.prod.outlook.com","subject":"Re: Improving support for name changes in git","fromName":"Gwyneth Morgan","fromEmail":"gwymor@tilde.club","sentAt":"2023-04-26T18:35:39Z","receivedAt":"2023-04-26T18:43:18Z","isPatch":false,"sender":{"key":"gwymor@tilde.club","avatar":"https://avatars.githubusercontent.com/u/87623694?v=4"},"body":"On 2023-04-04 18:00:00+0000, Bran Hagger wrote:\n> Has there been any further work done on supporting git name changes that I missed? Are there any existing files without git history that face similar issues?\n> \n> [1] https://code.googlesource.com/git/summit/2020/+/main/notes.md\n> [2] https://lore.kernel.org/git/20210103211849.2691287-1-sandals@crustytoothpaste.net/\n\nThere was another proposal posted by brian last year, using signing keys\nthe author controls instead of hashes:\nhttps://lore.kernel.org/git/20220919145231.48245-1-sandals@crustytoothpaste.net/T/\n\nA different VCS, Pijul, recently adopted a system that seems similar to\nbrian's proposal, and may provide some inspiration on the user\nexperience. I haven't seen documentation for it, but there are some\nexamples of commands here:\nhttps://nest.pijul.com/pijul/pijul/discussions/706\n"}]}