git rebase interactive already pushed commits

Question

Recently I had a lot of success rebasing a local-only repository while changing commit messages and after that only the commit messages had been changed but the history itself hasn't.

Now I have my repositories - remotely and locally. I made several commits on several branches and already pushed them. Due some reasons I need to change some commit masseages over several branches and tried to use rebase interactive like before. But the commits appeared at the end of the current checked out branch.

(I know how to and I had reset my repositories to the state before rebasing.)

After some reading I realized the problem is the commits had been pushed already which wasn't the fact in my local-only repository.

I tried to rebase the remote repository, but it's a bare one - so it didn't work.

I know its not recommended. But for learning purposes I really like to know how to change several commit messages without resulting in duplicate commits at the end of my branch / repository.

(I don't like the solution to work on, to copy and to change my local repository to a bare one as my new remote repository, which would solve my problem.)

I hope I made myself clear enough. Thanks.

Answer 1

Changing the commit message results in changing the commit's hash value and this means all following commits have to change their hashes too (as the parent is included in the hash computation, as the message itself is too).

This is why rebasing is typically only allowed in local branches. Many or say most git remote repositories permit rewriting the pushed history as anyone could have downloaded it already and would then work on a outdated history/branch/commit.

Strategy for preventing or catching git history rewrite

However if your server does allow history rewrites (e.g. if you are the only one working on it) you may push them with --force.

As a side note see here https://stackoverflow.com/a/5668050/1756183

Edit rebase with several branches:

C1 <- C2 <- C3 (branch1)

rebasing children of C1 results in

C1 <- CR2 <- CR2 (branch1)

But if you have:

          / C4 <- C5 (branch2)
C1 <- C2 <- C3 (branch1)

rebasing will most likely lead to:

    / C2 <- C4 <- C5 (branch2)
C1 <- CR2 <- CR3 (branch1)

the reason is that C2 is still the parent of C4, the "fixed" commit CR2 is only related to the rewritten Branch branch1. If you want to "forget" C2 you have to rebase C4 on top of CR2 (you ll have to play around with rebase --onto). After that C2 is not adressed as anyone's parent or on any branch and will not be shown in the history (although it is still there until garbage collected).