On Fri, Mar 19, 2010 at 06:53, Paolo Bonzini <bonzini@xxxxxxx> wrote:
>
>>> While a gnu.org or gmail.com will (most likely) stay with some
>>> person forever, hindsight is 20/20 and many people may generate
>>> his UUID from a work email. So, suppose I make my UUID based
>>> on<pbonzini@xxxxxxxxxx> what will guarantee that in 20 years I
>>> won't find a new career as a bartender, and Red Hat wouldn't hire
>>> someone with my same name, and give him the same email address?
>>
>> Firstly, the UUID need not be a name/email pair.
>
> That's what you lastly proposed generating it from.
No. Please go read.
>> Secondly, you're being ridiculous; even if that ridiculous scenario
>> played out not-infrequently
>
> It's not a matter of frequency. If you want a "UU" identification,
> collisions must not even happen *once*.
I've got news for you. The UUIDs generated by uuidgen CAN collide:
The new UUID can reasonably be considered unique
among all UUIDs created on the local system, and
among UUIDs created on other systems in the past
and in the future.
You're creating a straw man argument; conceptually, what I propose is
better than what the current system provides because it would decrease
the rate at which identity entropy increases.
>>> I have an idea. Start your own website uuidemail.com. One
>>> registers and gets an alias for their email, something like
>>> 8aacc35ffca0d34fccf8a750e84e3a81bdcb940b@xxxxxxxxxxxxxx Then
>>> people can start using
>>>
>>> 8aacc35ffca0d34fccf8a750e84e3a81bdcb940b+pbonzini--redhat.com@xxxxxxxxxxxxx
>>> as their git user.email. I bet nobody will.
>>
>> This is nonsense that betrays your misunderstanding.
>
> Why? What does (name, email, uuid) provide over (name, concat(uuid,
> email))? Nothing.
Go read the thread until you understand.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html