Re: What's in a name? Let's use a (uuid,name,email) triplet
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Mar 19, 2010, 14:08 UTC
- Message-ID
- <4BA3855A.1070005@alum.mit.edu>
- In-Reply-To
- <b4087cc51003190439x3c9ff269g35d11432bd2a3d60@mail.gmail.com>
Michael Witten wrote:
Show 18 quoted lines
> On Fri, Mar 19, 2010 at 02:41, Michael Haggerty <mhagger@alum.mit.edu> wrote: >> 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.
No, my point is to use the *existing* email address as the UUID *without* adding another field. Nothing needs to be changed!
> [...] 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.
Give me a break. It's not so damn hard to keep an email address over time. And if it changes, I can update the .mailcap file to map my old email address to the new one and *presto* I have a new, equally valid UUID that I can continue to commit under.
> 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.
Wrong. I've read the whole idiotic thread. To prove it I'll summarize it for you: you argue the same point over and over again while ignoring the legitimate objections of just about every other participant.
Adding a new UUID field is obviously a non-starter, so I suggested a way to get the same (very marginal) benefit from the fields that are already present in every git repository.
Michael