Question about rebasing - unexpected result, can't figure out why

Hi *,

I did some experimenting to understand rebasing better. I'm trying to follow ProGit 2nd edition. I used the repository example from here:

https://git-scm.com/book/en/v2/Git-Branching-Rebasing#rbdiag_e

I did a short test setup and did a few rebases, expecting a certain result from my limited understanding of rebases. Sadly, I got something else, and I can't figure out why.

== Setup ==

The repository is present in the attached archive in folder: ./rebase-experiment/repo-before-rebases/

The graph is as in the linked book example above. I set up the commits (named same as in the book) in the following way:

C1: adds file C1.txt
C2: adds file C2.txt
C3: adds file C3.txt
C4: adds file C4.txt
C5: adds file C5.txt
C6: adds file C6.txt
C8: deletes file C3.txt (following C3 which added it)
C9: adds file C9.txt
C10: adds file C10.txt

Then I did the following rebases:

git checkout client && git rebase master git checkout master && git merge client git checkout server && git rebase master git checkout master && git merge server

The resulting repository is present in the attached archive in folder: ./rebase-experiment/repo-after-rebases/

== Expected result ==

The result I expected on the master branch after the rebases was:

C1 -> c2 -> C3 -> C8 -> C9 -> C3 -> C4 -> C10 (with C3.txt present / readded at the end)

The actual result present in ./rebase-experiment/repo-after-rebases/ is:

C1 -> c2 -> C3 -> C8 -> C9 -> C4 -> C10 (with C3.txt not present / not readded at the end)

== Why did I expect that ==

Of course after the client rebase, C3.txt should be gone (since it's gone at the original last commit of the client branch).

But since it still exists in the server branch at the final commit, after rebasing & reapplying that onto the master, shouldn't it be put back in? Also, I would expect C3 -> C4 -> C10 as the complete chain of commits of the remaining server branch to be attached at the end, not just C4 -> C10...

Does git somehow detect C3 would be applied twice? Doesn't the commit hash of C3 change after it is rebased? So how exactly would it figure that out? I'm really unsure about what is going on.

Regards, Jonas Thiem

On Sat, Feb 10, 2018 at 09:47:57PM +0100, Jonas Thiem wrote:

Yes. The git rebase documentation says, "Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped)."

If you want to be very explicit about replaying these commits, you can say "git rebase --onto master $(git merge-base master HEAD)", in which case C3 will be replayed.