3

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 massages 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 this solution: 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.

cb4
  • 6,689
  • 7
  • 45
  • 57
codekandis
  • 712
  • 1
  • 11
  • 22

1 Answers1

2

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).

Community
  • 1
  • 1
dag
  • 1,133
  • 12
  • 25
  • I checked it out and I don't have such a git-config set on my server. In the other hand I already used: `git rebase --interactive SHA`, mark targeted commits with `reword`, `git push --force`. But the problem still exists. I already used the answere of http://stackoverflow.com/a/5668050/1756183 but the same problem. In your first link I found `receive.denyDeletes` which leads me to the idea to delete the remote branches, rebase my local history and pushing it then. No way ... problem remains. – codekandis Oct 05 '15 at 15:53
  • The problem might be that my current project has multiple branches when my first one didn't. – codekandis Oct 05 '15 at 15:56
  • Added some more informations to the post - that should explain the effects you see. – dag Oct 06 '15 at 17:31
  • Thank you for the detailed explanation. My case and my needs aren't worth this mess of rebasing. There are too many branches and commits involved. But as I told in the question it's good to know for learning purposes. So I'll create a repository trying this with a bunch of commits and I'll see what's happening. – codekandis Oct 08 '15 at 11:17
  • I recently started a new project and had the same problem while I had a development branch aside the master branch. After an interactive rebase of the development branch I locally had a new trunk representing my edited development branch without the development branch pointing to it. I reset my development branch on top of the new trunk HEAD while the remote development branch pointed the old trunk HEAD. After `git push --force` the remote branch pointed the new HEAD. The old branch has been removed automatically. A `interactive rebase` branch by branch will do the job easily. – codekandis Nov 11 '15 at 21:13
  • 2nd (not enough characters for last edit): After this trial'n'error I understood your solution completely. Thx again for your detailed solution. You already mentioned the garbage collection. – codekandis Nov 11 '15 at 21:14
  • using `--force-with-lease` instead of `--force` have added advantages as said [here](https://stackoverflow.com/a/37460330/1788684) – Binod Kalathil Oct 19 '18 at 10:42