git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
JTJonas Thiem <jonas@thiem.email>
Date
Feb 10, 2018, 20:47 UTC
Message-ID
<44e87a5a-b2be-f3f5-ac98-6831e056152d@thiem.email>
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

Next: brian m. carlson
Message 1 of 2 in “Question about rebasing - unexpected result, can't figure out why”
  1. Jonas ThiemFeb 10, 2018
  2. brian m. carlsonFeb 13, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.