How to force users to use email address in lowercase in GIT

Client side hooks are not reliable IMO (the client could always pass in --no-verify, or just remove the hook completely). You'd want to use a server side hook that would reject any pushes that had commits with bad email addresses, and then print out recovery instructions for the end user on how to redo their commits with proper email addresses.

If you have existing commits in published history you don't have any non-destructive options for fixing those.

-A

This is a very rough sample that only correctly handles an existing branch update. You will need to add a lot more cases to handle new branches, deletes, tags, etc., as well as instructions on how they can configure their email and how to recreate the commits with correct email information. But it should get you started.

.git/hooks/update

refname="$1"oldrev="$2"newrev="$3"for sha in $(git rev-list ${oldrev}..${newrev})do   git log ${sha}  --format="%ae %ce" -1 | grep [A-Z]   if [ $? -eq 0 ]   then      echo "SHA ${sha} contains an illegal email address containing uppercase characters"      git log ${sha} --format="%ae %ce" -1      exit 1   fidone

If you try to push a SHA you will get something like this

remote: SHA 49511d51548720f774b4a2bed113c43d06c32a34 contains an illegal email address containing uppercase characters remote: AndrewC@whoops.com remote: error: hook declined to update refs/heads/master To /scratch/email_repo ! [remote rejected] master -> master (hook declined)

I am not sure is it off-topic but why you have to force users to use email in lowercase? The local-part (part before @) of email address can be case sensitive.

Jeyanthan@serverA.com and JEYANTHAN@serverA.com can be a different email address and it's all depending on serverA.com.

See RFC

Verbs and argument values (e.g., "TO:" or "to:" in the RCPT commandand extension name keywords) are not case sensitive, with the soleexception in this specification of a mailbox local-part (SMTPExtensions may explicitly specify case-sensitive elements). That is,a command verb, an argument value other than a mailbox local-part,and free form text MAY be encoded in upper case, lower case, or anymixture of upper and lower case with no impact on its meaning. Thelocal-part of a mailbox MUST BE treated as case sensitive.

https://www.rfc-editor.org/rfc/rfc5321#section-2.4

http://en.wikipedia.org/wiki/Email_address#Common_local-part_semantics

If you find any problem importing upper case email address, i think it is NOT to address this issue in git but should be on that importing program

Have you considered addressing this in code delivery and peer review?

For example, you can adopt a practice where new deliveries are done on a feature branch and only once they are completed (and reviewed) they get merged into an integration branch. As a part of code review you can require that the person(s) performing the review check the commit history, by switching into the feature branch, for

1. Proper user.email
2. Proper user.name
3. Meaningful commit messages
4. Squashed commits for like changes

This approach does require discipline but the outcome would yield a 'clean' integration branch where you would not have to run git filter-branch all the time.

If you are using Github, and have forks and pull-requests in the picture, the same can be done but would have to be done before someone pushes the green 'merge this' button.