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

[Michael Witten <mfwitten@gmail.com>]

On Mon, Mar 22, 2010 at 06:06, Mark Brown <broonie@sirena.org.uk> wrote:
>
> You're assuming they aren't conflated - for example, when people do work
> both personally and for their employer they often use distinct e-mail
> addresses to identify how the work was funded.

Indeed.

The model I propose handles this case much better, as I explain here:

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

Specifically:

    > 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
    
    The user doesn't have a damn choice!

    [These first few paragraphs aren't completley correct;
     there's an explanation below them. It's mainly just
     setting up for the important part below.]
    
    The email can't be kept consistent over time because
    the tools expect it to be and/or use the actual
    physical email used to send/receive stuff. It's
    information that CONFLATES identity with whatever
    tool/system you're using.
    
    For instance, Michael Haggerty cannot reasonably use
    
        [user]
            name  = Michael Haggerty
            email = mhagger@MIT.EDU
    
    because he likely no longer has that email account
    to use. He is forced to change it and therefore
    forced to make his identity confused.

    [The above isn't quite true; my mistake. Michael
     could actually keep "mhagger@MIT.EDU" but inform
     tools like "git send-email" to send patches from
     another email address; this way, send-email will
     emit the necessary information to carry that
     authorship identity ("mhagger@MIT.EDU") along
     with the patch.
    
     However, it's still the case that Michael Haggerty
     is essentially stuck with "mhagger@MIT.EDU" for
     his identification---a problem that my proposal
     essentially fixes, as described now:]
    
    I'm proposing ALLOWING him to say:
    
        [user]
            uuid  = Michael Haggerty <mhagger@MIT.EDU>
            name  = Michael Haggerty
            email = mhagger@ALUM.mit.edu
    
    Heck, let's say he works at Red Hat as well; he
    might make some commits under this config AT WORK:
    
        [user]
            uuid  = Michael Haggerty <mhagger@MIT.EDU>
            name  = Michael Haggerty
            email = mhagger@redhat.com
    
    Then, he can make, say, commits to the Linux kernel
    repo for both work and hobby related issues and
    still be recognized as the same person.
    
    That is, he can have some commits [publicly] under:
    
        Michael Haggerty <mhagger@ALUM.mit.edu>
    
    and other commits [publicly] under:
    
        Michael Haggerty <mhagger@redhat.com>
    
    and still link them all together as the [SAME PERSON]
    with just the uuid:
    
        Michael Haggerty <mhagger@MIT.EDU>

The idea is to help users manage their own identities more effectively.

It's clearly advantageous to be able to apply different public identities
(personal vs. work identity for instance) to different commits, tags, etc.,
but it's also advantageous to be able to link those different identities
together.

At the moment, the different identities can only be linked together by
editing and transmitting a .mailmap file to be used by git tools. My
proposal distributes this kind of work UPFRONT by having individuals
choose UPFRONT some reasonably unique identification string to use
as the link between public identities.

Sincerely,
Michael Witten