[DISCUSS] validation on git config user.email

Hi, Git Community,

I'm a Git user and curious about a specific aspect of Git's design regarding the 'user.email' configuration.

Git allows any kind of values without restriction when setting 'user.email' via 'git config' (e.g., `git config user.email "not-a-valid-email-address"`).

I'm interested in understanding the design philosophy or historical reasons behind this 'lack' of validation.

I've glanced through the documentations, archived emails, or forum topics, but couldn't find a definitive or official statement.

Thanks for your time and insights.

On September 12, 2025 12:13 AM, usharerose wrote:

Some customers integrate single sign-on (SSO) via the user.email value. In the case of one customer I helped, the value is an SSO token used by GitHub for their integration. The token value does not conform to any valid email address format. Adding an email validation will lock them out of using git.

--Randall

<rsbecker@nexbridge.com> writes:

That is a very good point. We need to remember that not all users use the value of the field we define to be "email" to send emails to, just like some people use "name" field to store something that is not their name.

On Sat, Sep 13, 2025 at 12:29 AM Junio C Hamano <gitster@pobox.com> wrote:

Thanks for your reply, Junio.

My intention behind the original question was not to suggest adding the feature of validation for email legitimacy, but rather to inquire about and understand the rationale behind the initial design decision to forgo strict validation when the user identity feature (user.email) was implemented.

So, is the case ("not all users use the value of the field we define to be 'email' to send emails to") more of a case of "exploiting a perceived backdoor that later became justified" or "a thoughtfully made design decision from the beginning"?

On Fri, Sep 12, 2025 at 11:00 PM <rsbecker@nexbridge.com> wrote:

Thanks for your reply, Randall.

I've fully understood the scenario you described. My follow-up question is: was this use case something that was discovered and utilized later because people found that Git doesn't validate the email format, or was it a scenario that the architects anticipated early on in the project's history, leading to the deliberate decision to skip the validation for flexibility?

In other words, is this more of a case of "exploiting a perceived backdoor that later became justified" or "a thoughtfully made design decision from the beginning"?

Thanks again for sharing your insight.

On September 12, 2025 12:52 PM, usharerose wrote:

I cannot answer decisively. The functionality was first used in this customer about four years ago. I do not think any changes were required in git to accomplish this. It is possible GitHub had to have an enhancement but only they can answer that.

On Sat, Sep 13, 2025 at 1:23 AM <rsbecker@nexbridge.com> wrote:

Appreciate you sharing what you know, Randall. My intention behind the original question was not to suggest adding validation for email legitimacy, but rather to inquire about and understand the rationale behind the initial design decision to forgo strict validation when the user identity feature (user.email) was implemented.

I will try to find answers from other sources of information.

Thank you again for your help.

On Fri, Sep 12, 2025, at 17:00, rsbecker@nexbridge.com wrote:

That sounds unreasonable.

On September 14, 2025 7:18 AM, Kristoffer Haugsbakk wrote:

"not-a-valid-email-

In what way, may I ask? I have personally seen this done. Their core.email value is not a valid user name. It is a token with no @ or . characters. It is an alphanumeric string.

On Fri, Sep 12, 2025 at 12:13:07PM +0800, usharerose wrote:

That's a valid email address on the local system. It will get expanded into not-a-valid-email-address@localhost (or whatever domain is configured with the local MTA).

This may be insightful: https://e-mail.wtf

:)

-K

On 2025-09-12 00:13, usharerose wrote:

Hi usharerose,

To add to the other valid responses, email is something that can be validated by hooks server-side to enforce not only proper formatting but also valid users are being used, ex. validating against an LDAP directory.

This is much better that validating it at the command level (although IIRC git-comit does warn about possibly unset/invalid email addresses). In addition, unless git starts enforcing stricter rules on the commit message format (which would be a breaking change), nothing else can prevent someone from constructing commits with invalid emails, so checks by git-commit alone can't be strictly enforceable.

Furthermore, imported commits from other SCMs may have odd user name/email and it may be desirable to keep then in their original formats rather than turning them into fake email addresses.

Regards,

-- Thomas

On Fri, Sep 12, 2025 at 11:39 PM Thomas Guyot <tguyot@gmail.com> wrote:

Thanks for your detailed reply, Thomas. I've understood the scenarios you mentioned.

My intention behind the original question was not to suggest adding the feature of validation for email legitimacy, but rather to inquire about and understand the rationale behind the initial design decision to forgo strict validation when the user identity feature (user.email) was implemented.

So, are the use cases above mentioned more of a case of "exploiting a perceived backdoor that later became justified" or "a thoughtfully made design decision from the beginning"?

On Fri, Sep 12, 2025, at 06:13, usharerose wrote:

What’s the positive case for email validation?

On Sun, Sep 14, 2025 at 7:58 PM Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:

Thanks for your reply, Kris. My intention behind the original question was not to suggest adding validation for email legitimacy, but rather to inquire about and understand the rationale behind the initial design decision to forgo strict validation when the user identity feature (user.email) was implemented.

I've come across many explanations, but they mostly list the various application scenarios for `user.email` value. I haven't found an officially recognized answer regarding whether the above applications were explicitly considered during the initial design phase. Therefore, I would like to consult the official community here.

Thank you again for your help.