How to force users to use email address in lowerca

问题:

I'm looking for possibilities to confirm whether the email address of the committer is lower case to avoid issues like this.

I'm thinking to implement a client side pre-commit hook script which would either convert the upper case into lower case characters in the username and email or just warns the user to change in git config.

I don't want to write something like this every time I encounter with errors during import. This is not recommended, as it results in modification in the ref values and might break some contents.

$ git filter-branch --env-filter 'export
GIT_AUTHOR_EMAIL="[e-mail]";GIT_AUTHOR_NAME="Yourname"'

Please suggest me if there is any other better ways to achieve the same.

回答1:

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
   fi
done

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: [e-mail] remote: error: hook declined to update refs/heads/master To /scratch/email_repo ! [remote rejected] master -> master (hook declined)

回答2:

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.

[e-mail] and [e-mail] 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 command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions 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 any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive.

http://tools.ietf.org/html/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

回答3:

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.

回答4:

To be brutally honest, you have a people problem, not a technology problem. The real issue is that people are unaware or don't care.

Anyone with write access to the repo needs to be made aware of this and assisted. If you are dealing with 3rd parties, deny pull requests if they don't follow the standards.

回答5:

I would create a function mygit (or whatever name you want) as a wrapper to the normal git.

This for example checks every single argument that is given. In case they contain any character different from a digit, a lower case or a @, it shows an error and exits. Otherwise, the git command is executed normally.

mygit () {
    for var in "$@"
    do
      echo "arg is: $var"
          if [[ "$var" =~ [^0-9a-z@] ]]; then
        echo "argument $var has characters not being 0-9, a-z or @"
        return
      fi
    done
    git $@
}

To use it permanently, store it in your ~/.bashrc file. You can even make git itself behave like mygit does. You just need to set an alias: alias git=mygit or change the function to be called git.