Hosting a git clone of the Octave repository

@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 :slightly_smiling_face:

1 Like

After many trials and errors, I seem to have figured out a way to achieve this task.

  1. “git-cinnabar” was a dead end for this project. If someone knows how to get it right, I am interested :slightly_smiling_face:

  2. 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:

    default =
    github = git+ssh://

    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.

git-remote-hg to the rescue

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::"

# Use compression to shrink 2 GB to 200 MB.
git gc --aggressive

git remote add github

# 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                #"
git push github master stable  #

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.

1 Like

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

  1. inspect patches online
  2. extract the raw patch by adding .diff to the URL or the patch with commit message (hg changeset) by adding the .patch suffix

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 :slightly_smiling_face:

1 Like

Thanks for the info. The mentioned merge request is exactly the reason I was asking.

1 Like

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:sweat:

1 Like

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?

1 Like

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.

1 Like

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…

1 Like

Thanks for looking into this too. Your changes seem to better reflect our intentions and keep the synchronization service enabled :wink:

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 :innocent:

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 (

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 :slightly_smiling_face:

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 is luckily not world writable :sweat_smile:

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.

1 Like

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 :slightly_smiling_face:

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 :thinking:

Yes, @luisguerra, sorry.

1 Like