git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Witten <mfwitten@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: What's in a name? Let's use a (uuid,name,email) triplet
Date: Fri, 19 Mar 2010 08:40:31 -0600	[thread overview]
Message-ID: <b4087cc51003190740h680b5dech4edd7a5000f180ee@mail.gmail.com> (raw)
In-Reply-To: <m3tyscjt7h.fsf@localhost.localdomain>

On Fri, Mar 19, 2010 at 08:08, Jakub Narebski <jnareb@gmail.com> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> Short Version:
>> -------------
>>
>>
>> Rather than use a (name,email) pair to identify people, let's use
>> a (uuid,name,email) triplet.
>>
>> The uuid can be any piece of information that a user of git determines
>> to be reasonably unique across space and time and that is intended to
>> be used by that user virtually forever (at least within a project's
>> history).
>>
>> For instance, the uuid could be an OSF DCE 1.1 UUID or the SHA-1 of
>> some easily remembered, already reasonably unique information.
>
> ... or 'canonical-name canonical-email' pair.
>
>>
>> This could really help keep identifications clean, and it is rather
>> straightforward and possibly quite efficient.
>>
>>
>> Long Version:
>> ------------
> [...]
>
>> While git's use of (name,email) pairs to identify each person is
>> extremely practical, it turns out that it's rather `unstable';
>
> This is non-solution to non-problem.
>
> First, the user.name and user.email does not need to be name and email
> from some email account.  It might be some "canonical name" and
> "canonical email".

The vast majority of patches come in through email; the git tools
expect the user.name and user.email to reflect physical email account
information.

You would be correct if it were not for the fact that git currently
conflates identity and current email system.

> Second, there are (I think) two main sources of 'unstability' in
> (name,email) pairs, namely A) misconfigured git (when fetching/pushing
> using git itself), B) wrong name in email etc. (when sending patches
> via email, 80% of patches in Linux kernel case).
>
> In the case of misconfigured git (case A) using UUID wouldn't help,
> and only make it worse (you would have to configure the same UUID on
> each machine).  What would help here is for git to be more strict and
> perhaps forbid (some of) autogenerated names and emails.

The uuid string would be typed pretty much only during configuration;
from there, it's basically just handled by the git tools. Hence, the
uuid can indeed suffer from typos, but the name/email pair can suffer
from not only typos but also real life name changing and email account
switching.

There would still be the same problem of variations in uuid for one
person, but the problem would very likely be greatly reduced; if a
person doesn't use the uuid properly or at all, then we're in the
exact same situation we were before. Those who do use it, though, will
be much better off.

Strictness about names and emails is difficult, and keeping something
like the current .mailmap file up-to-date is a centralized process.
The uuid field would distribute the responsibility of maintaining
identity and make that responsibility easy because the user-chosen
string is easy for that user to remember and is typed only very
occasionally and under very specific circumstances.

> In the case of sending patches via email, you can use in-body 'From:'
> to provide (name,email) part that is different than account used to
> send email.

That's a good solution that I've considered, except for 2 reasons:

    * It involves much more opportunities for typos and/or the
      configuration of a non-git tool for a git-specific purpose.

    * Many if not most email services will refuse to send messages
      with forged/spoofed email addresses.

> In the case of UUID you would need the same: some way to
> provide UUID in patch (in email).

Yes, but that's automated by tools like git's format-patch. Not using
something like format-patch or some other git interface is an
'out-of-band' communication and that author has essentially chosen not
to care about his identity.

The use of the uuid field and allowing git tools to handle it is just
a way to give a person who does care about his identity to keep it
consistent.

> UUID has the disadvantage of being
> required also when (name,email) in From: email header is good user ID.
> So UUID wouldn't help there either.

It's not a good user id because it depends on factors other than identity.

> What could help in both cases is .mailmap being used (perhaps on
> demand) in more git commands.  See Documentation/mailmap.txt
> or e.g. git-shortlog(1) manpage.  It is quite advanced tool for
> correcting mistakes (it can correct *both* user name, which is
> most common usage, but also email address).

The disadvantage here is that it centralizes identity management and
it is more demanding because the name/email pair is quite unstable.

On the other hand, something like a uuid field would distribute that
management to the user himself and frees that user from the influences
of legal name changing and email address switching.

Of course, as already stated, some people may bungle their uuid
setting. Then something like .mailmap can be used, but the format
would be simpler, the file would not grow nearly as quickly, and with
some clever encoding some statistics gathering programs could
(possibly) run more efficiently.

  parent reply	other threads:[~2010-03-19 14:41 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18 13:23 What's in a name? Let's use a (uuid,name,email) triplet Michael Witten
2010-03-18 13:48 ` Jon Smirl
2010-03-18 14:26   ` Michael Witten
2010-03-18 17:27 ` Linus Torvalds
2010-03-18 19:02   ` Jon Smirl
2010-03-18 19:07     ` Linus Torvalds
2010-03-18 19:16       ` Jon Smirl
2010-03-18 19:20         ` Linus Torvalds
2010-03-18 19:37           ` Jon Smirl
2010-03-18 19:47             ` Linus Torvalds
2010-03-18 19:50               ` Linus Torvalds
2010-03-18 20:01                 ` Linus Torvalds
2010-03-19 19:39                   ` Junio C Hamano
2010-03-18 20:31                 ` Reece Dunn
2010-03-18 20:59                   ` Linus Torvalds
2010-03-18 19:32       ` Michael Witten
2010-03-18 19:40         ` Linus Torvalds
2010-03-18 19:47           ` Michael Witten
2010-03-18 19:52             ` Linus Torvalds
2010-03-18 20:00               ` Michael Witten
2010-03-18 19:52             ` Wincent Colaiuta
2010-03-18 19:40         ` Wincent Colaiuta
2010-03-18 19:42         ` Martin Langhoff
2010-03-18 22:36   ` Martin Langhoff
2010-03-18 23:17     ` Nicolas Pitre
2010-03-18 23:26       ` Jon Smirl
2010-03-18 23:34         ` Nicolas Pitre
2010-03-18 23:41           ` Jon Smirl
2010-03-18 23:58             ` Nicolas Pitre
2010-03-19  0:16               ` Jon Smirl
2010-03-19  0:17                 ` Linus Torvalds
2010-03-19  0:39                   ` Jon Smirl
2010-03-19  0:50                     ` Linus Torvalds
2010-03-19  1:12                       ` Jon Smirl
2010-03-19  1:45                         ` Nicolas Pitre
2010-03-19  2:05                           ` Jon Smirl
2010-03-18 23:34       ` Michael Witten
2010-03-18 18:42 ` Michael Witten
2010-03-18 18:47   ` Matthieu Moy
2010-03-18 18:57     ` Michael Witten
2010-03-18 19:12   ` Nicolas Pitre
2010-03-18 20:44   ` tytso
2010-03-18 21:12     ` Michael Witten
2010-03-18 21:19       ` Martin Langhoff
2010-03-18 21:29         ` Michael Witten
2010-03-18 21:39           ` Martin Langhoff
2010-03-18 21:46             ` Michael Witten
2010-03-18 21:55               ` Martin Langhoff
2010-03-18 22:02                 ` Michael Witten
2010-03-18 23:37                   ` Nicolas Pitre
2010-03-18 23:44                     ` Michael Witten
2010-03-19  0:03                       ` Nicolas Pitre
2010-03-19  0:27                         ` Michael Witten
2010-03-19  0:32                           ` Nicolas Pitre
2010-03-18 22:06               ` Reece Dunn
2010-03-18 21:57             ` Michael Witten
2010-03-19 12:34               ` Paolo Bonzini
2010-03-19 12:43                 ` Michael Witten
2010-03-19 12:53                   ` Paolo Bonzini
2010-03-19 13:03                     ` Michael Witten
2010-03-19 13:08                       ` Paolo Bonzini
2010-03-19 13:13                         ` Michael Witten
2010-03-19 13:41                           ` Wincent Colaiuta
2010-03-19 13:59                             ` Michael Witten
2010-03-19 14:13                               ` Martin Langhoff
2010-03-18 21:27       ` Linus Torvalds
2010-03-18 21:44         ` Michael Witten
2010-03-18 23:12         ` Jon Smirl
2010-03-18 22:17 ` A Large Angry SCM
2010-03-19  2:47 ` Sitaram Chamarty
2010-03-19  5:17   ` Nazri Ramliy
2010-03-19  8:41 ` Michael Haggerty
2010-03-19 11:39   ` Michael Witten
2010-03-19 11:45     ` david
2010-03-19 11:54       ` Mike Hommey
2010-03-19 12:09         ` Reece Dunn
2010-03-19 12:16           ` Michael Witten
2010-03-19 12:18             ` Michael Witten
2010-03-19 14:57             ` Reece Dunn
2010-03-19 15:26               ` Michael J Gruber
2010-03-19 16:05                 ` david
2010-03-19 17:16                   ` Michael Witten
2010-03-19 12:25           ` Jon Smirl
2010-03-19 12:40             ` Reece Dunn
2010-03-19 12:09         ` Michael Witten
2010-03-22 12:06           ` Mark Brown
2010-03-22 14:38           ` Michael Witten
2010-03-24 19:18             ` Erik Faye-Lund
2010-03-24 19:23               ` Michael Witten
2010-03-19 12:08       ` Michael Witten
2010-03-19 14:08     ` Michael Haggerty
2010-03-19 17:02       ` david
2010-03-19 17:06         ` Michael Witten
2010-03-24 18:50           ` Avi Kivity
2010-03-19 14:08 ` Jakub Narebski
2010-03-19 14:33   ` Jon Smirl
2010-03-19 14:52     ` Michael J Gruber
2010-03-19 14:40   ` Michael Witten [this message]
2010-03-19 14:56     ` Erik Faye-Lund
2010-03-19 15:05       ` Michael Witten
2010-03-19 15:12         ` Michael Witten
2010-03-19 15:25         ` Erik Faye-Lund
2010-03-19 15:12     ` Reece Dunn
2010-03-20  0:21     ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4087cc51003190740h680b5dech4edd7a5000f180ee@mail.gmail.com \
    --to=mfwitten@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).