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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- 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 --]