On Fri, Sep 12, 2025 at 11:39 PM Thomas Guyot [off-list ref] wrote:

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.

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