Re: Question about rebasing - unexpected result, can't figure out why
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Feb 13, 2018, 00:36 UTC
- Message-ID
- <20180213003624.GC1022467@genre.crustytoothpaste.net>
- In-Reply-To
- <44e87a5a-b2be-f3f5-ac98-6831e056152d@thiem.email>
On Sat, Feb 10, 2018 at 09:47:57PM +0100, Jonas Thiem wrote:
Show 14 quoted lines
> == 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