Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > Quoting Adam Megacz <adam@xxxxxxxxxx> > >> Perhaps a preference (off by default) demanding that they be set >> explicitly when "git commit -m" is used? > > Sverre pointed out why this won't work. > >> Some people care more than others about the metadata; this is for the >> folks to whom it matters a lot. > > So the only workable solution is to check your commits with "git show > -s" until you become confident that you configured your new box > correctly. Some people unfortunately don't care enough to do so, but it > is for the people to whom it matters. Traditionally, we've only had a minimal sanity check (e.g. to barf when the name is empty, or something silly like that) and tried to come up with a reasonable name/email given the available system information. The approach may have been Ok 10 years ago, back when `whoami`@`hostname`, at least on systems that were competently maintained, gave a reasonable mail address for most people, but I don't think it is adequate anymore to majority of people, especially the ones who work on Open Source projects as individuals, whose desired public identities are often tied to their email account at their ISPs or mailbox providers (like gmail), and there is no way for us to guess what it is from `whoami` nor `hostname` [*1*]. So I don't think anybody minds if we refuse to work if we are going to end up using a name that we didn't get from an explicit end user configuration (i.e. GIT_*_EMAIL and GIT_*_NAME environment and user.* configuration variables). [Footnote] *1* Inside corporate environments, `whoami`@`hostname -f` might still be a reasonable and usable default, though. -- 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