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="yourname@example.com";GIT_AUTHOR_NAME="Yourname"'
Please suggest me if there is any other better ways to achieve the same.
I would create a function
mygit
(or whatever name you want) as a wrapper to the normalgit
.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.To use it permanently, store it in your
~/.bashrc
file. You can even makegit
itself behave likemygit
does. You just need to set an alias:alias git=mygit
or change the function to be calledgit
.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 anintegration
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, foruser.email
user.name
This approach does require discipline but the outcome would yield a 'clean'
integration
branch where you would not have to rungit 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.
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.
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
If you try to push a SHA you will get something like this
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 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