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

From: Michael Witten <mfwitten@gmail.com>
Date: Mar 19, 2010, 11:39 UTC
Message-ID: <b4087cc51003190439x3c9ff269g35d11432bd2a3d60@mail.gmail.com>
In-Reply-To: <4BA338C1.7030803@alum.mit.edu>

On Fri, Mar 19, 2010 at 02:41, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 12 quoted lines

> Michael Witten wrote:
>> Rather than use a (name,email) pair to identify people, let's use
>> a (uuid,name,email) triplet.
>> [...]
>
> A UUID doesn't need to be a big hex number.  All it has to be is a
> "Universally Unique Identifier".  Like, oh, for example, your
>
>                   *** EMAIL ADDRESS ***
>
> [1].  There is even already a way to fix up mistakes or unavoidable
> email address changes, namely the .mailmap file.

*facepalm*

You've just repeated everything that I've said; go look at the rest of the thread, where I spend plenty of time correcting the same hangups about my choice of the word UUID and my use of hex digits.

I'm only observing that the current name/email system pair conflates an individual with his current email system and that it would be worthwhile to ALLOW an individual to FURTHER describe himself by including another piece of information that is solely meant as identification within git. That piece of information could be whatever a user deems to be uniquely identifying for himself. You could use "Michael Haggerty <mhagger@alum.mit.edu>" as your uuid, and you could still use it after you change the `email' config variable to something else.

There is MUCH LESS CHANCE of such a uuid getting trashed by typos, changing names, and changing email addresses; of course it can still get messed up, but the rate at which something like .mailmap would need to be updated would likely be greatly decreased and it would make gathering statistics easier (especially for the individuals who take advantage of such a uuid for describing themselves---and it only requires setting one config variable to something easily remembered by that person).

I cover all of this numerous times in numerous rebuttals; don't contribute to a thread with more than 60 emails without having read at least some of them. If you don't care to read so much, then perhaps jump here:

    http://marc.info/?l=git&m=126894679711600&w=2

In the end, there is probably only one legitimate problem with my proposal: It might break compatibility with older repo formats/tools. I'm not sure about that.

Sincerely, Michael Witten