I was writing a simple script in the school computer, and committing the changes to Git (in a repo that was in my pendrive, cloned from my computer at home). After several c
As docgnome mentioned, rewriting history is dangerous and will break other people's repositories.
But if you really want to do that and you are in a bash environment (no problem in Linux, on Windows, you can use git bash, that is provided with the installation of git), use git filter-branch:
git filter-branch --env-filter '
if [ $GIT_AUTHOR_EMAIL = bad@email ];
then GIT_AUTHOR_EMAIL=correct@email;
fi;
export GIT_AUTHOR_EMAIL'
To speed things up, you can specify a range of revisions you want to rewrite:
git filter-branch --env-filter '
if [ $GIT_AUTHOR_EMAIL = bad@email ];
then GIT_AUTHOR_EMAIL=correct@email;
fi;
export GIT_AUTHOR_EMAIL' HEAD~20..HEAD
When taking over an unmerged commit from another author, there is an easy way to handle this.
git commit --amend --reset-author
This is a more elaborated version of @Brian's version:
To change the author and committer, you can do this (with linebreaks in the string which is possible in bash):
git filter-branch --env-filter '
if [ "$GIT_COMMITTER_NAME" = "<Old name>" ];
then
GIT_COMMITTER_NAME="<New name>";
GIT_COMMITTER_EMAIL="<New email>";
GIT_AUTHOR_NAME="<New name>";
GIT_AUTHOR_EMAIL="<New email>";
fi' -- --all
You might get one of these errors:
If you want to force the run in spite of these errors, add the --force
flag:
git filter-branch --force --env-filter '
if [ "$GIT_COMMITTER_NAME" = "<Old name>" ];
then
GIT_COMMITTER_NAME="<New name>";
GIT_COMMITTER_EMAIL="<New email>";
GIT_AUTHOR_NAME="<New name>";
GIT_AUTHOR_EMAIL="<New email>";
fi' -- --all
A little explanation of the -- --all
option might be needed: It makes the filter-branch work on all revisions on all refs (which includes all branches). This means, for example, that tags are also rewritten and is visible on the rewritten branches.
A common "mistake" is to use HEAD
instead, which means filtering all revisions on just the current branch. And then no tags (or other refs) would exist in the rewritten branch.
If you are the only user of this repo or you don't care about possibly breaking the repo for other users, then yes. If you've pushed these commits and they exist where somewhere else can access them, then no, unless you don't care about breaking other people's repos. The problem is by changing these commits you will be generating new SHAs which will cause them to be treated as different commits. When someone else tries to pull in these changed commits, the history is different and kaboom.
This page http://inputvalidation.blogspot.com/2008/08/how-to-change-git-commit-author.html describes how to do it. (I haven't tried this so YMMV)
The fastest, easiest way to do this is to use the --exec argument of git rebase:
git rebase -i -p --exec 'git commit --amend --reset-author --no-edit'
This will create a todo-list that looks like this:
pick ef11092 Blah blah blah
exec git commit --amend --reset-author --no-edit
pick 52d6391 Blah bloh bloo
exec git commit --amend --reset-author --no-edit
pick 30ebbfe Blah bluh bleh
exec git commit --amend --reset-author --no-edit
...
and this will work all automatically, which works when you have hundreds of commits.
One liner, but be careful if you have a multi-user repository - this will change all commits to have the same (new) author and committer.
git filter-branch -f --env-filter "GIT_AUTHOR_NAME='Newname'; GIT_AUTHOR_EMAIL='new@email'; GIT_COMMITTER_NAME='Newname'; GIT_COMMITTER_EMAIL='new@email';" HEAD
With linebreaks in the string (which is possible in bash):
git filter-branch -f --env-filter "
GIT_AUTHOR_NAME='Newname'
GIT_AUTHOR_EMAIL='new@email'
GIT_COMMITTER_NAME='Newname'
GIT_COMMITTER_EMAIL='new@email'
" HEAD