It's a common misconception that user input can be filtered. PHP even has a (now deprecated) "feature", called magic-quotes, that builds on this idea. It's nonsense. Forget about filtering (or cleaning, or whatever people call it).
What you should do, to avoid problems, is quite simple: whenever you embed a a piece of data within a foreign code, you must treat it according to the formatting rules of that code. But you must understand that such rules could be too complicated to try to follow them all manually. For example, in SQL, rules for strings, numbers and identifiers are all different. For your convenience, in most cases there is a dedicated tool for such an embedding. For example, when you need to use a PHP variable in the SQL query, you have to use a prepared statement, that will take care of all the proper formatting/treatment.
Another example is HTML: If you embed strings within HTML markup, you must escape it with htmlspecialchars. This means that every single echo or print statement should use htmlspecialchars.
A third example could be shell commands: If you are going to embed strings (such as arguments) to external commands, and call them with exec, then you must use escapeshellcmd and escapeshellarg.
Also, a very compelling example is JSON. The rules are so numerous and complicated that you would never be able to follow them all manually. That's why you should never ever create a JSON string manually, but always use a dedicated function, json_encode() that will correctly format every bit of data.
And so on and so forth ...
The only case where you need to actively filter data, is if you're accepting preformatted input. For example, if you let your users post HTML markup, that you plan to display on the site. However, you should be wise to avoid this at all cost, since no matter how well you filter it, it will always be a potential security hole.
NOTE: This answer changes SHA1s, so take care when using it on a branch that has already been pushed. If you only want to fix the spelling of a name or update an old email, git lets you do this without rewriting history using .mailmap. See my other answer.
Using Interactive Rebase
You could do
git rebase -i -p <some HEAD before all of your bad commits>
Then mark all of your bad commits as "edit" in the rebase file. If you also want to change your first commit, you have to manually add it as the first line in the rebase file (follow the format of the other lines). Then, when git asks you to amend each commit, do
git commit --amend --author "New Author Name <email@address.com>"
edit or just close the editor that opens, and then do
git rebase --continue
to continue the rebase.
You could skip opening the editor altogether here by appending --no-edit
so that the command will be:
git commit --amend --author "New Author Name <email@address.com>" --no-edit && \
git rebase --continue
Single Commit
As some of the commenters have noted, if you just want to change the most recent commit, the rebase command is not necessary. Just do
git commit --amend --author "New Author Name <email@address.com>"
This will change the author to the name specified, but the committer will be set to your configured user in git config user.name and git config user.email. If you want to set the committer to something you specify, this will set both the author and the committer:
git -c user.name="New Author Name" -c user.email=email@address.com commit --amend --reset-author
Note on Merge Commits
There was a slight flaw in my original response. If there are any merge commits between the current HEAD and your <some HEAD before all your bad commits>, then git rebase will flatten them (and by the way, if you use GitHub pull requests, there are going to be a ton of merge commits in your history). This can very often lead to a very different history (as duplicate changes may be "rebased out"), and in the worst case, it can lead to git rebase asking you to resolve difficult merge conflicts (which were likely already resolved in the merge commits). The solution is to use the -p flag to git rebase, which will preserve the merge structure of your history. The manpage for git rebase warns that using -p and -i can lead to issues, but in the BUGS section it says "Editing commits and rewording their commit messages should work fine."
I've added -p to the above command. For the case where you're just changing the most recent commit, this is not an issue.
Update for modern git clients (July 2020)
Use --rebase-merges instead of -p (-p is deprecated and has serious issues).
Best Answer
Users created by SCM are not "full" users. They are created for purposes of showing SCM changes and receiving e-mails. Therefore they need to sign up (using 'Sign Up' icon that appears to the left of of 'log in' icon in the upper right corner) and provide their password. It is advisable for the username to match the SCM name.
Alternatively, a user with a "full" account can go to
http://<jenkins-server>/people/-> click on username -> click on Configure link to the left, and configure the user (I'm not 100% sure if this will work, though, try it).