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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: rebase-experiment.tar.gz
Description: application/gzip


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux