Multiple user.name and user.email (possible feature request)

Is there a way to have *no* default or some invalid default for the name/email -- something that will make git refuse to create a commit?

For example, I'd be happy if I could put this in my global config:

  [user]
    name = "Eli Barzilay"
    email = "-"

and then have git barf at me when I try to commit with these settings, since I prefer being forced to set the appropriate address for each repository rather than deal with the alternative confusion (or just accepting the limitations and always using the same name/email).

[When I tried to see if it's possible I was surprised to see that git happily creates commits for "- <->" and even " <>".]

On Apr 18, 2010, at 2:12 AM, Eli Barzilay wrote:

Eli,

Just set the variable in the repository, not the global config.

i.e. drop the --global flag. So, in your repository: git config user.email "that-repos-config"

I have three different email address for different repositories on my computer. I have my global config set with my most common address, and the repositories with the less common email set locally in the repository.

Steve

On Sun, Apr 18, 2010 at 11:16:34AM -0700, Steven Michalske wrote:

I think the key is that he wants git to barf if he forgets to set the repo-only config, instead of quietly using the global config.

Sine 1.7.0, git will complain loudly if you simply don't have your identity set at all. There is no way to make it actually refuse the commit, but the warning is quite gigantic and hard to miss:

  $ git config --global --unset user.name
  $ git config --global --unset user.email
  $ git commit -m foo
  [master 7c2a927] foo
   Committer: Jeff King <peff@c-71-185-130-222.hsd1.va.comcast.net>
  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

  If the identity used for this commit is wrong, you can fix it with:

      git commit --amend --author='Your Name <you@example.com>'

   1 files changed, 1 insertions(+), 0 deletions(-)

So I expect that will serve Eli's purpose.

-Peff

Heya,

On Sun, Apr 18, 2010 at 20:37, Jeff King <peff@peff.net> wrote:

If it does not, would a pre-commit hook work? If he sets some recognizable string (such as not setting it) as email and install a hook that barfs if it sees that?

On Sun, Apr 18, 2010 at 08:43:11PM +0200, Sverre Rabbelier wrote:

Yeah, that could work. It would do what he wants, but he would have to have the hook set up. Which means he either needs to remember to configure it in each repository (at which point he could just remember to configure his identity), or he needs to point to a special init template directory with the hook.

I think setting init.templatedir or GIT_TEMPLATE_DIR in the environment would accomplish the latter.

-Peff

On Apr 18, Steven Michalske wrote:

(As already guessed) I really do want it to error instead of guessing. My problem is that I'm very often checking out trees of one project (and starting from today that svn-checkout has been replaced by a git clone), and I will definitely get confused. (It seems to me that this is a common source of problems, leading to much flammage.)

On Apr 18, Jeff King wrote:

Well, that would get closer, but I'd really prefer if there was a do-not-use-me value I could set. But in any case, even this is not working for me -- digging through my environment, I found that I have EMAIL set to my email, and so git guesses my name and doesn't produce that huge response.

Worse, if I set up

  [user]
    name = ""
    email = ""

in my ~/.gitconfig (and make sure that I don't have EMAIL set), then git still guesses the values -- without any warning.

On Apr 18, Jeff King wrote:

Yes, that sounds like it will work, and I'll do that. But in general this well beyond what most people would do. If it was done as I suggested (actually, how I thought it would behave), then this whole thing would be easy even for people who are afraid of shell programming...

On Apr 18, Eli Barzilay wrote:

... when 1.7.1 is out. That's probably enough time for me to make a mistake.