if a repo is in the manifest, we don't give out push access, let alone force push, and certainly not to the entire repo

please explain what precisely it is you want to do

Reassign this to Chris

(I'd typed a long draft, but then accidentally closed the tab).

Re:Comment #2.

In summary:
1. Intel maintains the upstream versions of the repos in the description text.
2. cros versions are snapshots from Intel's tree. We build (or, at least the long term plan) is to build from our local source copies. These builds are outside of the cros chroot (using XCC proprietary toolchains). GCC instructions are available for external developers should they choose to customize (hence we keep copies of the source).
3. cros tree's "master" was synced to the Intel release branch which they were providing/building a release firmware from. The earlier understanding was that fixes in their release branch would be ported to their master, and hence we could merely fastforward our "master" to their latest release branch.
4. 3.) is not being followed. Their release branch fixes don't apply cleanly to their master branch. As a result we can't fast forward. This churn is likely a consequence of teething issues, and getting the release out in time, leading to bespoke unportable fixes on the release branch.
5. Given 1-4, we may need to reset our "master" branch to their "master" branch (to the point where they branch their release branches). Moving forward we will inform Intel to push their release branch changes to our release branches (and we will build from the release branch).
6. I'm not working on this actively at present (cujomalainey@ dgreid@ are), so would like to give them temporary force privileges to set the tree states as necessary.
7. Once we get the master branching on track, we can revoke all force push privileges.

sorry, but that's 100% not acceptable and will def break CrOS.  once a commit is in the master branch, the history must never be changed.

if Intel is doing sep release branches, then you want to follow that in CrOS. 
 i.e. create new branches that correspond to their sep release branches.  then update the manifests to point to those new branches when a new one comes out.

so i guess that means you don't need push (or force) access ?

if Intel creates new branches often (once a month?), we could give access to creating new branches with a specific pattern (e.g. chromeos-xxx).  that way you wouldn't have to ask for manual support every time this comes up.  then you'd just have to update the manifest to switch to the new branch which you can run through the CQ like normal.