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

From: Greg Troxel <gdt@ir.bbn.com>
Date: Aug 12, 2013, 12:51 UTC
Message-ID: <rmieh9zdqcf.fsf@fnord.ir.bbn.com>
In-Reply-To: <20130810102834.GA6237@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty 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.
>
> 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.