git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's in a name? Let's use a (uuid,name,email) triplet

From
RDReece Dunn <msclrhd@googlemail.com>
Date
Mar 19, 2010, 14:57 UTC
Message-ID
<3f4fd2641003190757y39050691y3dc0ca08bd5196fb@mail.gmail.com>
In-Reply-To
<b4087cc51003190516h42202e34k598a163c246cb9f2@mail.gmail.com>
On 19 March 2010 12:16, Michael Witten <mfwitten@gmail.com> wrote:
Show 52 quoted lines
> On Fri, Mar 19, 2010 at 06:09, Reece Dunn <msclrhd@googlemail.com> wrote:
>> On 19 March 2010 11:54, Mike Hommey <mh@glandium.org> wrote:
>>> On Fri, Mar 19, 2010 at 04:45:38AM -0700, david@lang.hm wrote:
>>>> here is where you are missing the point.
>>>>
>>>> no, there is not 'much less chance' of it getting messed up.
>>>>
>>>> you seem to assume that people would never need to set the UUID on
>>>> multiple machines.
>>>>
>>>> if they don't need to set it on multiple machines, then the
>>>> e-mail/userid is going to be reliable anyway
>>>>
>>>> if they do need to set it on multiple machines and can't be bothered
>>>> to keep their e-mail consistant, why would they bother keeping this
>>>> additional thing considtant? Linus is pointing out that people don't
>>>> care now about their e-mail and name, and will care even less about
>>>> some abstract UUID
>>>>
>>>> people who care will already make their e-mail consistant.
>>>
>>> While I don't agree with the need for that uuid thing, I'd like to
>>> pinpoint that people who care can't necessarily make their e-mail
>>> consistant. For example, Linus used to use an @osdl.org address, and
>>> he now uses an @linux-foundation.org address. It's still the same Linus,
>>> but the (name, email) pair has legitimately changed.
>>
>> So create an aliases list that maps one (name,email) to another that
>> is from the same person. There is no need for an additional item (a
>> uuid) to solve this problem. It also means that searching on any
>> (name,email) pair will find the others, so you only need to
>> remember/find one of the identities for the person you are interested
>> in finding the commits for.
>>
>> AFAICS, mailmap is about correcting mistakes (primarily in the
>> reported name for a given email address). In this case, mailmap and
>> this aliases-map will work in conjunction with each other to give what
>> the original poster wanted. However, I haven't seen any of his replies
>> that answer this (or sufficiently address why mailmap does not solve
>> his problem).
>
> See:
>
>    http://marc.info/?l=git&m=126900051102958&w=2
>
> The idea is to distribute the responsibility for maintaining a
> consistent identity AND to make that responsibility EASY.
>
> The extra uuid `field' can only suffer from typos, while the
> name/email pair can suffer from typos, changing email accounts, and
> changing real life names. If the uuid `field' does get bungled by a
> typo or is not used, then we're no worse off than we were before.
What specific problem(s) are you trying to solve?

The main issue is identifying who made what changes to a repository (e.g. by a script, or database/statistics algorithms). The mailmap file allows for corrections to a canonical (name,email) pair for a specified repository.

For identifying the same person working across multiple projects, ideally they should keep the canonical (name,email) pair consistent across all projects, with mailmap files in the respective projects to keep the canonical form correct.

This canonical (name,email) pair is then a unique identifier for that person and then effectively becomes a uuid. There is no need to add an extra uuid field that needs *more* work fixing up errors and making consistent.

If you change email address or name, *and* care enough about it being consistent, there is no reason why you cannot update the mailmap file to use the new canonical (name,email) pair.

Oh, and you are expressing it wrong (if I understand you correctly)...
What you are after is a string U (the uuid) that is used to identify a
person irrespective of their name and email. At the moment
   U = (name,email)
is used to achieve that, with mailmap to normalise the variations.
What you are trying to express is:
    U <=> (name,email)
where U can be any unique string. This is different from using a
(name,email,uuid) triple to identify someone.
So, lets say that I choose U=abc to identify myself uniquely, so that:
    "abc" <=> "Reece Dunn <msclrhd@gmail.com>"
    "abc" <=> "Reece Dunn <msclrhd@googlemail.com>"
    "abc" <=> "Reece Dunn <msclrhd@hotmail.com>"
    "abc" <=> "Reece H. Dunn <msclrhd@gmail.com>"
    "abc" <=> "Reece H Dunn <msclrhd@gmail.com>"

I would still need to define all these variations when and as they occur in a repository to fixup any typos and email address changes that occur, so why not just pick U = "Reece H. Dunn <msclrhd@gmail.com>" as the canonical form instead of "abc" or some other string?

As has been said, mailmap supports name variations ("Reece Dunn", "Reece H Dunn", "Reece H. Dunn") and email variations (msclrhd@hotmail.com, msclrhd@gmail.com, msclrhd@googlemail.com), so how does a string that I need to set on the git client in addition to name and email help me define a canonical form *in the git repository*?

So, I'll ask again: what problems are you trying to solve that cannot be solved by mailmap?

- Reece
Previous: Michael WittenNext: Michael J Gruber
Message 79 of 104 in “What's in a name? Let's use a (uuid,name,email) triplet”
  1. Michael WittenMar 18, 2010
  2. Jon SmirlMar 18, 2010
  3. Michael WittenMar 18, 2010
  4. Linus TorvaldsMar 18, 2010
  5. Michael WittenMar 18, 2010
  6. Matthieu MoyMar 18, 2010
  7. Michael WittenMar 18, 2010
  8. Nicolas PitreMar 18, 2010
  9. tytso@mit.eduMar 18, 2010
  10. Michael WittenMar 18, 2010
  11. Martin LanghoffMar 18, 2010
  12. Michael WittenMar 18, 2010
  13. Martin LanghoffMar 18, 2010
  14. Michael WittenMar 18, 2010
  15. Martin LanghoffMar 18, 2010
  16. Michael WittenMar 18, 2010
  17. Nicolas PitreMar 18, 2010
  18. Michael WittenMar 18, 2010
  19. Nicolas PitreMar 19, 2010
  20. Michael WittenMar 19, 2010
  21. Nicolas PitreMar 19, 2010
  22. Reece DunnMar 18, 2010
  23. Michael WittenMar 18, 2010
  24. Paolo BonziniMar 19, 2010
  25. Michael WittenMar 19, 2010
  26. Paolo BonziniMar 19, 2010
  27. Michael WittenMar 19, 2010
  28. Paolo BonziniMar 19, 2010
  29. Michael WittenMar 19, 2010
  30. Wincent ColaiutaMar 19, 2010
  31. Michael WittenMar 19, 2010
  32. Martin LanghoffMar 19, 2010
  33. Linus TorvaldsMar 18, 2010
  34. Michael WittenMar 18, 2010
  35. Jon SmirlMar 18, 2010
  36. Jon SmirlMar 18, 2010
  37. Linus TorvaldsMar 18, 2010
  38. Jon SmirlMar 18, 2010
  39. Linus TorvaldsMar 18, 2010
  40. Jon SmirlMar 18, 2010
  41. Linus TorvaldsMar 18, 2010
  42. Linus TorvaldsMar 18, 2010
  43. Linus TorvaldsMar 18, 2010
  44. Junio C HamanoMar 19, 2010
  45. Reece DunnMar 18, 2010
  46. Linus TorvaldsMar 18, 2010
  47. Michael WittenMar 18, 2010
  48. Linus TorvaldsMar 18, 2010
  49. Michael WittenMar 18, 2010
  50. Linus TorvaldsMar 18, 2010
  51. Michael WittenMar 18, 2010
  52. Wincent ColaiutaMar 18, 2010
  53. Wincent ColaiutaMar 18, 2010
  54. Martin LanghoffMar 18, 2010
  55. Martin LanghoffMar 18, 2010
  56. Nicolas PitreMar 18, 2010
  57. Jon SmirlMar 18, 2010
  58. Nicolas PitreMar 18, 2010
  59. Jon SmirlMar 18, 2010
  60. Nicolas PitreMar 18, 2010
  61. Jon SmirlMar 19, 2010
  62. Linus TorvaldsMar 19, 2010
  63. Jon SmirlMar 19, 2010
  64. Linus TorvaldsMar 19, 2010
  65. Jon SmirlMar 19, 2010
  66. Nicolas PitreMar 19, 2010
  67. Jon SmirlMar 19, 2010
  68. Michael WittenMar 18, 2010
  69. A Large Angry SCMMar 18, 2010
  70. Sitaram ChamartyMar 19, 2010
  71. Nazri RamliyMar 19, 2010
  72. Michael HaggertyMar 19, 2010
  73. Michael WittenMar 19, 2010
  74. david@lang.hmMar 19, 2010
  75. Mike HommeyMar 19, 2010
  76. Reece DunnMar 19, 2010
  77. Michael WittenMar 19, 2010
  78. Michael WittenMar 19, 2010
  79. Reece DunnMar 19, 2010
  80. Michael J GruberMar 19, 2010
  81. david@lang.hmMar 19, 2010
  82. Michael WittenMar 19, 2010
  83. Jon SmirlMar 19, 2010
  84. Reece DunnMar 19, 2010
  85. Michael WittenMar 19, 2010
  86. Mark BrownMar 22, 2010
  87. Michael WittenMar 22, 2010
  88. Erik Faye-LundMar 24, 2010
  89. Michael WittenMar 24, 2010
  90. Michael WittenMar 19, 2010
  91. Michael HaggertyMar 19, 2010
  92. david@lang.hmMar 19, 2010
  93. Michael WittenMar 19, 2010
  94. Avi KivityMar 24, 2010
  95. Jakub NarebskiMar 19, 2010
  96. Jon SmirlMar 19, 2010
  97. Michael J GruberMar 19, 2010
  98. Michael WittenMar 19, 2010
  99. Erik Faye-LundMar 19, 2010
  100. Michael WittenMar 19, 2010
  101. Michael WittenMar 19, 2010
  102. Erik Faye-LundMar 19, 2010
  103. Reece DunnMar 19, 2010
  104. Jakub NarebskiMar 20, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.