On Fri, Sep 12, 2025 at 11:39 PM Thomas Guyot <tguyot@xxxxxxxxx> 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"?
