1

I have this scenario. I had a develop branch which goes like this:

c1->c2->c3-----develop

then I checkout my feature branch from develop and made some commits while other people continued to commit in develop branch.

c1->c2->c3->c7->c8->c9----develop
         |
         |--c4->c5->c6----feature

After a while, instead of doing rebase, I did git merge develop in my feature branch. So it became like this:

c1->c2->c3->c7->c8->c9----develop
         |           \
        c4->c5->c6->c10----feature

where c10 is merged commit. Then I continued to do some commits in my feature branch.

c1->c2->c3->c7->c8->c9----develop
         |           \
        c4->c5->c6->c10->c11->c12----feature

Then, I wanted that only commits made by me should come at top of my branch. So , I did interactive rebase in my feature branch.

git rebase -i c3

and reordered commits. Now since I reordered, I got new commit hashes.

c1->c2->c3->c7'->c8'->c9'->c4'->c5'->c6'->c10'->c11'->c12'

Now my commits are on top of my branch and I squashed my commits(c4'..c12').

c1->c2->c3->c7->c8->c9 ------develop
         |
         c7'->c8'->c9'->c13' -----feature (c13 is squashed)

Now when I do git rebase develop, as per my understanding my branch should be on top of develop branch and should looks like this(c7",c8",c9",c13" are new hashes):

c1->c2->c3->c7->c8->c9->c7"->c8"->c9"->c13"-----feature

However, git restores original hashes and feature branch looks like this(c7,c8,c9 restored):

c1->c2->c3->c7->c8->c9->c13"-----feature

How does git identify copied hashes and restored them while doing rebasing ?

Vivek Mangal
  • 532
  • 1
  • 8
  • 24
  • The short answer is "it doesn't" - but due to patch ID computations, it's possible that if the original commits already exist on the branch onto which you're rebasing, those will remain, and the new copies will be dropped. – torek Jun 04 '22 at 00:52

0 Answers0