I'm working for some time with an - exclusively local - branch dev by standard rebasing on an organisations remote master branch:
o-----o-----o dev (local branch)
/
--o-----o--- master
o'-----o'-----o' dev
/
--o-----o-----o-- master
etc.
Not so currently, the organisation switched to another branch as basis for main development.
o'-----o'-----o' dev
/
----o-----o-----o-- master
\
o-----o-----o-----o-----o-- new_master
For reasons beyond the topic here, I was unable to sync my changes with the remote master before this happened and continued to surf on top of master locally, updating further from the remote master and rebasing on it with dev.
Now, before consuming my results, the organisation would like have my work rebased (in general and specific meaning) on new_master.
o'-----o'-----o'-- dev (former)
/ | how/when?
----o-----o-----o-----o-----o-+--- master
\ | how/when?
o-----o-----o-----o-----o---- new_master
\
o''-----o''-- dev (new: maintain old dev commits)
My guess is, I have to wait for a merge between master and new_master (x) after the commit, I am currently based on with dev (a), before I can rebase again (after or at (x)) directly on new_master:
o'-----o'-----o' dev (former)
/
----o-----o-----a-----b-----c--- master
\ \ merge?
o-----o-----o-----o-----x-- new_master
\
o''-----o''-- dev
Is this correct, or I'm missing some unintended rewrite of history specifically of new_master when finally merging dev with it?
This is done like this:
git rebase --onto new_master master dev
So.... take all dev revisions, discard revisions on master, put them on top of new_master