Jon Smirl venit, vidit, dixit 19.03.2010 15:33: > On Fri, Mar 19, 2010 at 10:08 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> Michael Witten <mfwitten@xxxxxxxxx> 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". >> >> 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). > > Another top source is mangling of non-ASCII charsets when they go > though the email system. Are the git work flow tools safe for > alternative charsets? Do the email tools look at the charset header of > the email message? Check people's names in the kernel commits and > you'll find lots of examples of this type of mangling. > Or even the quoting of quotes for nick names, appearing as 'nick', "nick", \"nick\", nick and what not. > Or people not using UTF-8. There are files in the kernel where > people's names are in conflicting codepages. Should git try to look > for diffs that aren't UTF-8? You and others are proving a very important point here: This is really an lkml proxy fight being taken to the git list, after the futile mailmap-ification there. People may disagree on the best approach in general, but this thread clearly shows: - The Git community is happy with mailmap for git.git. - The Git community does not see any need for amending the mailmap mechanism. - How you actually use mailmap (leniently or enforcing) is a per-project decision, just like the patch workflow, the meaning and use of s-o-b lines, the requirement for full names and many other things. But since the git list is hosted on kernel.org we can't really complain about providing room for an lkml discussion ;) Michael -- 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