On Fri, Aug 09, 2013 at 12:42:14PM -0700, Jonathan Nieder wrote:
> I wonder if it's too gentle and long to get the point across. Would
> something the following (including the guesses in the message for
> easier copy-pasting) help?
>
> No name and email address configured, so I had to guess. You
> can suppress this message by setting your identity explicitly:
>
> git config --global user.name "Thorsten Glaser"
> git config --global user.email tg@xxxxxxxxx
>
> After doing so, you may fix the identity used for this commit
> with "git commit --amend --reset-author".
I don't know if including the name and email helps that much. It should
already be printed along with that message, like:
$ git commit --allow-empty -m foo
[master ba77f94] foo
Committer: Jeff King <peff@xxxxxxxxxxxxxxxxxxxxx>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name "Your Name"
git config --global user.email you@xxxxxxxxxxx
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
> It may also make sense to distinguish between cases where a mailname
> is set and not set. Git already notices the cases where the guessed
> email address ends with ".(none)" and errors out, and it could make
> sense to be more aggressive.
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.
We can put a deprecation warning in the release notes, but people tend
to ignore those. Or perhaps now that we have had the long obnoxious
implicit-ident warning for several versions, everybody has finally set
user.email and the time is right to change.
Another option could to add an option to control the strictness. We
usually have a chicken-and-egg problem here with individual installs
(i.e., any person who could set "user.trustHostname = false" could just
as easily have set "user.email"). But in an institutional setting, the
admin could set such a config in /etc/gitconfig for everybody. Or for a
system like Debian, the packager could include the option, knowing that
any reasonably configured system should have /etc/mailname set up (which
is not something we can necessarily count on for other operating
systems).
-Peff
--
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