this was actually not that dangerous since everyone who synced the git history (i.e. at least @max-sixty) before that accident had a full "backup" of the commit history.

Would it make sense to add a section for "people with commit access" to contributing.rst? I imagine this could be useful as a reference and for new maintainers...

you could try to undo that by: getting the hash of the latest commit (7bf9df9d75c40bcbf2dd28c47204529a76561a3f right now), then calling sh git reset <hash> git push -f

Since I've been afraid of that mistake as well, I added a git hook that makes git refuse to push to master and stable on the main repository (use --no-verify to override it): ```bash $ cat .git/hooks/pre-push

!/usr/bin/env bash

protected_remotes="origin" protected_branches="master stable"

isin() { local list="$1" local substring="$2"

for element in $list
do
    [[ "$element" == "$substring" ]] && return 0;
done

return -1;

}

readonly() { remote="$1" branch="$2"

if isin "$protected_remotes" "$remote" && isin "$protected_branches" "$branch"
then
    return 0;
else
    return -1;
fi

}

remote="$1"

IFS=" " while read local_ref local_sha remote_ref remote_sha do branch="$(echo $remote_ref | sed 's#^refs/heads/##g')" if readonly "$remote" "$branch" then echo "cannot push to $remote/$branch: protected branch. Use --no-verify to override this." exit -1 fi done ```

see this SO question. However, I don't think we should try that since there are a few cases where you still need to push without a PR (releasing, mainly). So I think either a pre-push hook or git config branch.master.pushRemote no_push (but then you also can't push to your own master anymore) are the best way forward

oh, yeah. Then someone with the appropriate permissions (you? or maybe @shoyer?) has to temporarily remove the branch protection (settings on github), force push, and then add back the branch protection.