Consider a local repo, managed by gerrit, that is regularly synced from a github-based project (with the appropriate tracking branches/tags. Development was initialized on version 1 of the code (tag = 1.0). Development is being done on that code and is regularly merged to the internal develop branch via gerrit, and perhaps to a internal release/master branch as well.
Eventually, though, it is desired that we move to external v2.0, or that we pull all changes from our release line (after it diverges from develop).
Given this is code managed via gerrit, would you directly rebase the develop branch to bring in the internal/external "upstream" changes to your develop line, or would you branch from develop, rebase a developer branch to v2.0, then push the developer branch through gerrit the usual way?
I ask because the former seems out-of-band within this framework... from what I've read on the subject (such as here) such a rebase-in-place may not be possible within gerrit, and might be unwanted if we're regularly pushing everything to other teams (which may eventually occur). The latter (pull-via-developer-branch) seems more robust, and doesn't require the developer to have special privileges to bypass gerrit or the normal development process.
Your thoughts?
