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
signature.asc
Description: PGP signature
