From: Jonathan Nieder <hidden> Date: 2016-06-15 22:58:23
Hi Thorsten,
Thorsten Glaser wrote[1]:
git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)
because just too many cow-orkers seem to be unable to follow basic
instructions
Heh.
Can you say a little more about your setup? In a university
environment with sysadmin-managed email and /etc/mailname set up
correctly it is handy that people can start working without doing
anything special to configure git's "[user] email" setting. On the
other hand it is obnoxious to receive patches with wrong authorship
information. So I'm wondering if there's some detail that
distinguishes between these cases.
Incidentally, it's been a long time since I looked at the "Please
configure your email address; I've made something up, but you'll want
to check it" message:
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@example.com
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
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@mirbsd.de
After doing so, 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.
Hope that helps,
Jonathan
[1] http://bugs.debian.org/719226
Can you say a little more about your setup? In a university
environment with sysadmin-managed email and /etc/mailname set up
correctly it is handy that people can start working without doing
Ah okay. We don’t have /etc/mailname set up I think and,
additionally, the Unix user name doesn’t match the eMail
localpart, so that won’t work anyway.
Though we’re having a very heterogenous desktop environment
nowadays so I can’t really know all specifics.
At least, I think, most devs seem to use the Unix git client
now, whereas for svn they use the one that comes with Eclipse…
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?
Definitely not. It needs to fail hard if user.email is not set,
i.e. refuse to accept the commit.
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.
The guessed addresses are like 'denge@pc-bn-041.lan.tarent.de'
instead of 'd.enge@tarent.de' which is the correct Kolab address
(this information can be publicly accessed since the project I
noticed it in is on our public FusionForge instance, so I don’t
think sharing specifics is bad here, but please don’t hammer our
poor trainee with spam now). So they’re a “correct” unix username
at a correct FQDN (which, thanks to split-horizon, even would
work internally, except there’s of course no MTA set up) and
won’t be caught by *.(none) matches.
Hope this helps.
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:23
On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser [off-list ref] wrote:
Jonathan Nieder dixit:
quoted
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?
Definitely not. It needs to fail hard if user.email is not set,
i.e. refuse to accept the commit.
Completely agree, and I argued this point some time ago.
quoted
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.
The guessed addresses are like 'denge@pc-bn-041.lan.tarent.de'
instead of 'd.enge@tarent.de' which is the correct Kolab address
(this information can be publicly accessed since the project I
noticed it in is on our public FusionForge instance, so I don’t
think sharing specifics is bad here, but please don’t hammer our
poor trainee with spam now). So they’re a “correct” unix username
at a correct FQDN (which, thanks to split-horizon, even would
work internally, except there’s of course no MTA set up) and
won’t be caught by *.(none) matches.
This is how to implement that:
From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001
From: Felipe Contreras 2nd <redacted>
Date: Tue, 13 Nov 2012 07:33:12 +0100
Subject: [PATCH] ident: don't allow implicit email addresses
Signed-off-by: Felipe Contreras <redacted>
---
ident.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:58:23
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@mirbsd.de
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 [off-list ref]
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@example.com
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
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:58:23
Jeff King wrote:
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
From: Jeff King <hidden> Date: 2016-06-15 22:58:23
On Fri, Aug 09, 2013 at 04:19:28PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
quoted
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.
Just to nitpick, the name we guess is not necessarily from DNS (and if
the FQDN comes from DNS, it is not a reverse lookup, but rather
following the search rules in resolv.conf, or even /etc/hosts). But I
think the point is the same: we somehow arrive at the hostname through
some accurate means, but that hostname does not reflect the user's
actual email address.
* 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.
I'm not sure the second one is true. Many large installations will MX
all of their workstations names to a smarthost. So mail to
user@randommachine.example.com _is_ deliverable. It has (thankfully)
been a long time since I have been involved in large network IT, but
that was standard practice at one time.
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit history for all time?
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.
I think the other case is "people who actually think the per-machine
information is useful". I recall Linus arguing for this early on, but he
seems to have relented. I am not sure whether anyone else in the world
has that view (or ever did).
There are certainly people in the "I don't care, just make it work"
camp, judging from the repositories I sometimes see on GitHub. Whether
we would be harming them (because their workflow breaks) or helping them
(because they had no idea they had these crappy idents in their history
and we would be letting them know) is not clear to me, though.
quoted
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 meant a warning to give people a chance to comment before the change
comes. Following this mailing list is another source for people to find out
about it, but I suspect most casual users do not read the list. Perhaps
it would be worth taking a straw poll over G+ or another more casual
medium?
-Peff
From: Michael Haggerty <hidden> Date: 2016-06-15 22:58:23
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit history for all time?
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set user.email on my first commit, because I
invariably forget to set it myself. And for me, *any* universal,
heuristically-determined email address would be wrong for me for at
least some repos.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Jeff King <hidden> Date: 2016-06-15 22:58:23
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
On 08/10/2013 08:47 AM, Jeff King wrote:
quoted
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit history for all time?
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set user.email on my first commit, because I
invariably forget to set it myself. And for me, *any* universal,
heuristically-determined email address would be wrong for me for at
least some repos.
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said "please set
your identity before committing"?
-Peff
From: Michael Haggerty <hidden> Date: 2016-06-15 22:58:23
On 08/10/2013 12:28 PM, Jeff King wrote:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
quoted
On 08/10/2013 08:47 AM, Jeff King wrote:
quoted
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit history for all time?
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set user.email on my first commit, because I
invariably forget to set it myself. And for me, *any* universal,
heuristically-determined email address would be wrong for me for at
least some repos.
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said "please set
your identity before committing"?
Yes, definitely.
For the particular use case that I described, I wouldn't mind setting a
global setting "barfOnMissingEmail = true" because I always use the same
Linux account. But for other uses cases that arise at my company,
people have to jump around from one computer to another, and it would be
more convenient if the barfing behavior was the default without the need
for a setting.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
It was not clear to me whether his site has /etc/mailname. If it does
Some may, some may not but…
But from his description, the machine may even have a split-horizon name
in /etc/mailname, and we can do nothing at all about that.
… that won’t happen. The problem is that they may have
the correct domain there but the localpart will still
be wrong because Kolab localparts are not Unix usernames.
Jonathan Nieder dixit:
I thought that on other operating systems people typically don't have
an /etc/mailname. How does trusting the file when present hurt?
Right, MirBSD doesn’t have it, and I don’t think OpenBSD
added it since we forked.
Jeff King dixit:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
quoted
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
For me that’s also true, but I set a default one at the moment
which is still better than having an unroutable one (on my private
laptop, ${unix_username}@${fqdn} does work, but only as long as my
laptop is powered on, has got IPv6 Internet, and the sending MTA
has IPv6 Internet, so… it’s mostly unroutable).
While I used a fallback for this scenario (me, privately), I’d
also benefit from git refusing to accept commits by default.
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said "please set
your identity before committing"?
Exactly. That’s what I think he said, and what I asked for too.
Thanks,
//mirabilos (working with many OSS projects)
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
At 11:59 +0200 10 Aug 2013, Michael Haggerty [off-list ref] wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set user.email on my first commit, because I
invariably forget to set it myself. And for me, *any* universal,
heuristically-determined email address would be wrong for me for at
least some repos.
I was in a similar situation for awhile. Except in my case I had $EMAIL
set for other reasons, so I didn't get the reminder even if git wasn't
configured.
The solution I came up with was to use a template directory to have the
following script installed as a pre-commit hook in all new repos:
#!/bin/sh
git config user.email > /dev/null && exit
echo 'Set email address with `git config user.email` first' >&2
exit 1