Git log Merge branch 'master' of central repo

Question

I use this script to change author for specific commits:

#!/bin/sh

git filter-branch --env-filter '
NEW_NAME="MyName"
NEW_EMAIL="my-name@my-domain.com"
if [ "$GIT_COMMIT" = "afdkjh1231jkh123hk1j23" ]
then
    export GIT_COMMITTER_NAME="$NEW_NAME"
    export GIT_COMMITTER_EMAIL="$NEW_EMAIL"
    export GIT_AUTHOR_NAME="$NEW_NAME"
    export GIT_AUTHOR_EMAIL="$NEW_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

from Change commit author at one specific commit

After run on main repo, all commits was duplicated with different hash and commit with hash 'afdkjh1231jkh123hk1j23' was duplicated with another hash with the specified name and email. Can I return to the original log?

The problem is: now, after each commit is generated a new commit with merge with previous commit.

For example:

last commit was 601dd3a...

after run script

last commits:

commit 1550a7c596...
Merge: 601dd3a 4c882eb
Author: MyName <my-name@my-domain.com>
Date:   Sat Oct 14 17:59:09 2017 +0000
    Merge branch 'master' of 14.235.21.116:/app

commit 4c882eb.. (this is copy of 601dd3a)
........

commit 601dd3a...
......

And after new pull is generated this merge commit. Can it be eliminated in the future (for new commits)?

Follow your linked question to its own linked predecessor, https://stackoverflow.com/q/750172/1256452, and pay careful attention to the comments and answers there. The problem is that you are not *changing* a commit, you are making a *new* commit (and hence a new and different repository from that point onwards) and you can no longer relate this one to its original or you will see exactly the duplication you are seeing. — torek, Oct 14 '17 at 20:44
Is possible to remove merge commit for new commit, because now, after each pull on live is generate a merge commit. — BlackWhite, Oct 14 '17 at 21:00
You can reset away the merge commit. The problem is your repository *can no longer be used with the other repositories* that have the old commits, otherwise it will *keep coming back*. This is the reason you should not change history: to change history you must get *everyone* to change, not just make the change yourself, otherwise every time you merge your new history with their old history, you get the combined histories. — torek, Oct 14 '17 at 21:07
@globula_alba Can you show the commit history as a graph by `git log --oneline --decorate --graph --all`? And if the commits `1550a` and `4c882` are the only commits you need to remove? — Marina Liu, Oct 24 '17 at 09:45

score 0 · Answer 1 · answered Oct 15 '17 at 00:09

after each pull on live is generate a merge commit.

That is expected, since the remote branch has a different history (different SHA1) as your own local hostory (rewritten by the filter-branch)

If you change commits (or commit metadata like the author name/email), that means you are supposed to push --force and replace the remote history with your own.
That is easy to do if you are the only one working on (pushing to )that remote repo.
It is not so easy when you have multiple collaborators, because that would imply for them to not pull (they would get the same kind of merge commits as the ones you have), but to reset their own local repo to the remote repo branch (since that branch has a revised history).

Git log Merge branch 'master' of central repo

1 Answers1