Re: git should not use a default user.email config value

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 9, 2013, 23:19 UTC
Message-ID: <20130809231928.GY14690@google.com>
In-Reply-To: <20130809223758.GB7160@sigill.intra.peff.net>

Jeff King wrote:

Show 15 quoted lines

> Yeah, there are basically three levels of ident:
>
>   1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
>
>   2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
>      but use it.
>
>   3. It looks obviously bogus (e.g., we do not have a domain name).
>      Reject it.
>
> We can move some cases from (2) down to (3), like when we use
> gethostname rather than /etc/mailname.  But we risk breaking people's
> existing setups. I don't think we know how many people rely on the
> implicit hostname selection and would be affected. I don't know if there
> is a good way to find out short of changing it and seeing who screams.

Yes. The result from a reverse DNS lookup is almost never the right mailname.

 * Small installations tend to use a smarthost.
 * Large installations tend to use more than one machine, and only
   one machine's name gets the MX record.
 
So except for cases where someone doesn't actually care about the
recorded author and just has a script making commits (such users
already suffer from the ".(none)" heuristic), I don't think this would
hurt anyone.

> We can put a deprecation warning in the release notes, but people tend
> to ignore those.

Not so much a deprecation warning as an "Here is one of the more noticeable changes in this release" announcement.

I'm pretty sure a deprecation warning would not help here. Either people are affected and we say "WARNING: You were doing something perfectly reasonable, but now we discourage it", or, more likely, people are not affected. Announcing a change too loudly to users not affected by it has a very bad side effect of training them not to pay much attention to release notes.

[...]

> Another option could to add an option to control the strictness.

I suspect a new config item for this is a bad idea, given how simple it is to choose a good default for everyone.

Thanks, Jonathan