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

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

[Jonas Thiem]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

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 #2: rebase-experiment.tar.gz --]
[-- Type: application/gzip, Size: 22484 bytes --]

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

On Sat, Feb 10, 2018 at 09:47:57PM +0100, Jonas Thiem wrote:
> == 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.

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.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]