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

Jeff King [off-list ref] writes:

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
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"?

I also think it's a bug that git will create commits without an
explicitly-set author.  I've seen multiple cases of the author being
something unreasonable in a shared/official repository because of this.
One was a person's personal email address on a work-repo commit,
apparently because on Mac there was some magic extraction of primary
email address from Mail.app (but I'm not 100% clear on what happened).
If name/mail are not explicitly set, failing and making the user set
them seems like the right thing.

I find all the discussion of /etc/mailname to be a bit perplexing.  The
notion that the externally-visible email of a person making a commit
should be the same as if they sent mail from that machine seems to be a
bit of a stretch.  And their username might be different.  I don't think
it's possible to reliably figure out what ought to be in the git author
field.

Another reason to fail rather than use a possibly-wrong default is that
it's very difficult (if not impossible, depending on local CM policy
about forced updates in shared repos) to recover from pushing a commit
with a bad email address.  (And the people that don't set their email
right are the same people that won't run "git log -p @{u}.." before
pushing.)  But failing and having to set it manually is easy (people who
are already competent will be slowed down a minute or two, and the
others need to learn anyway), results in something that should have been
done anyway, and has no long-term negative consequences.