@mtmiller was it possible to update your git-mirror again and to describe your setup? You mentioned that you use git-cinnabar. So far I did not find the right tweaks to only push the default and stable branch. Then I can host an automatically updated git mirror, too.
If you are further interested, you might consider moving your git mirror in some Octave GitHub organization?
Thank you 
After many trials and errors, I seem to have figured out a way to achieve this task.
“git-cinnabar” was a dead end for this project. If someone knows how to get it right, I am interested
Using hg-git came already very close and was very straight forward. The basic idea is to work in a Mercurial repository and convert to git if necessary.
With this Mercurial extension installed, you can edit .hg/hgrc:
[paths]
default = https://www.octave.org/hg/octave
github = git+ssh://git@github.com:gnu-octave/octave.git
and call hg push github. Works all quite, but the resulting repository is 2 GB in size (the original Mercurial repository weights about 240 MB.
The opposite direction to “hg-git” goes “git-remote-hg”. The basic idea is to work in a git repository that embraces a Mercurial one.
With the git extension installed:
git clone "hg::https://www.octave.org/hg/octave"
# Use compression to shrink 2 GB to 200 MB.
git gc --aggressive
git remote add github git@github.com:gnu-octave/octave.git
# Default "master" branch is immediately available.
# Create local "stable" branch.
git checkout branches/stable
git branch -m stable
# Push with release tags.
git push --tags github
Now to automatically keep the Mercurial and GitHub repos in sync, I established a 5 minutes cron-job with
git pull origin # https://www.octave.org/hg/octave"
git push github master stable # https://github.com/gnu-octave/octave
Final note: also this approach suffers from the lack of object compression in the git repositiory. But in contrast to the “hg-git” approach, one can easily compress the repository locally using the git gc command.
Hey @siko1056, sorry for the late reply, I haven’t been computing much in the last month or so. I don’t have any specific steps written down to reproduce my setup, but as I recall getting started with git-cinnabar was fairly easy. Once it’s working, it is a simple matter of clone, pull, and push, similar to yours.
The primary advantage of git-cinnabar in my understanding is that it’s the best (only?) two-way bridge to allow pushing from a git branch to a hg remote repository.
As far as I understand, the mirror of the octave hg repo on github only synchronizes from hg to github, is that correct? Consequently, it would be useless to merge pull requests from github forks directly into the mirrored repo on github?
This is correct. Do you refer to:
What I like about GitHub and this way of providing patches is that you can
.diff to the URL https://github.com/gnu-octave/octave/pull/7.diff or the patch with commit message (hg changeset) by adding the .patch suffix https://github.com/gnu-octave/octave/pull/7.patch
Git patches are compatible with Mercurial and can be imported as usual Savannah provided ones.
Thus if you find the patch useful, please add it with ease to the hg repository 
Thanks for the info. The mentioned merge request is exactly the reason I was asking.
In regard of Fix comment of pushed hg commit? I must correct my bold statement
to “Git patches are compatible with Mercurial, but need editing of the commit message, before publication for clarity” 
Also, non-ASCII characters in the author field are encoded differently and need to be adapted manually (UTF-8 for Mercurial or RFC 2047(?) for Git).
It looks like changes have been pushed to the Octave repository mirror on GitHub (accidentally?). This seems to have stopped the synchronization with the Mercurial repository.
@siko1056: Could you please look into this? Maybe force push with a “clean” state of the mirror?
To prevent that from happening again, is it possible to restrict write access such that only the mirroring bot can push to that repository?
Thanks for the hint @mmuetzel . A forced push seems to have resolved the situation.
To avoid this from happening in the future, I tried out the branch protection rules and enforce those rules to all users including administrators. When the next commit to the hg repo happens, I look if the mirror-service faces any restrictions.
I pushed an update to the Mercurial repository about 10 minutes ago. Usually the GitHub mirror picked up the changes pretty fast. It hasn’t updated until now.
Edit: I added your account as the only one to have push access to that repository and removed the requirement for pull requests. Unless you also changed something in the meantime, that seems to enabled the synchronization again…
Thanks for looking into this too. Your changes seem to better reflect our intentions and keep the synchronization service enabled 
P.S.: I did not know that the deploy key of the synchronization service acted in my name, but it makes sense in a way 
hmmm…
I guess that didn’t work like I hoped it would. Another push the the GitHub “read-only” mirror. This time a new branch:
gnu-octave/octave at new-icons4 (github.com)
Is there no way to really have a read-only repository except for one single user?
This is indeed not nice, but stable and default were left intact. The sync bot could still do its work and I deleted the respective new branch from the GitHub website. If this does not happen too frequently, I can deal with this. But any help or advise with better GitHub configuration within organizations is pretty welcome
Maybe I am missing something here, but isn’t a public repository initially readable by all but only writable by the owner? Why is the octave repository writable to all?
The git clone https://github.com/gnu-octave/octave is luckily not world writable 
This repository is owned by the GitHub “gnu-octave” organization. Thus every of the 30 members has in general push rights, which @mmuetzel and I tried to better restrict to the sync-bot working under my user credentials.
In general I like the idea of having a community being able to manage this semi-official repository (e.g. “bus-factor”). But like any other community effort, we have to deal with mistakes (especially from new or less git affine contributors). For me this part of open-source development and this is probably what happened here.
Okay, thanks for the explanation. I understood the recent posts as if José, who is working on the new icons but is not a member, was able to push a new branch.
And now as I have read your comment in the related pull request I see that thee wasn’t a new branch in the original repository but only in the forked one. Sorry for the noise
Who is José? Are we talking about go-home icon by luisrguerra · Pull Request #17 · gnu-octave/octave · GitHub and @luisrguerra? He is member of the “gnu-octave” organization 