Next: , Previous: , Up: Contributing   [Contents][Index]

16.8 Commit Access

For frequent contributors, having write access to the repository is convenient. When you deem it necessary, consider applying for commit access by following these steps:

  1. Find three committers who would vouch for you. You can view the list of committers at Each of them should email a statement to (a private alias for the collective of maintainers), signed with their OpenPGP key.

    Committers are expected to have had some interactions with you as a contributor and to be able to judge whether you are sufficiently familiar with the project’s practices. It is not a judgment on the value of your work, so a refusal should rather be interpreted as “let’s try again later”.

  2. Send a message stating your intent, listing the three committers who support your application, signed with the OpenPGP key you will use to sign commits, and giving its fingerprint (see below). See, for an introduction to public-key cryptography with GnuPG.

    Set up GnuPG such that it never uses the SHA1 hash algorithm for digital signatures, which is known to be unsafe since 2019, for instance by adding the following line to ~/.gnupg/gpg.conf (see GPG Esoteric Options in The GNU Privacy Guard Manual):

    digest-algo sha512
  3. Maintainers ultimately decide whether to grant you commit access, usually following your referrals’ recommendation.
  4. If and once you’ve been given access, please send a message to to say so, again signed with the OpenPGP key you will use to sign commits (do that before pushing your first commit). That way, everyone can notice and ensure you control that OpenPGP key.

    Important: Before you can push for the first time, maintainers must:

    1. add your OpenPGP key to the keyring branch;
    2. add your OpenPGP fingerprint to the .guix-authorizations file of the branch(es) you will commit to.
  5. Make sure to read the rest of this section and... profit!

Note: Maintainers are happy to give commit access to people who have been contributing for some time and have a track record—don’t be shy and don’t underestimate your work!

However, note that the project is working towards a more automated patch review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository. Stay tuned!

If you get commit access, please make sure to follow the policy below (discussions of the policy can take place on

Non-trivial patches should always be posted to (trivial patches include fixing typos, etc.). This mailing list fills the patch-tracking database (see Tracking Bugs and Patches).

For patches that just add a new package, and a simple one, it’s OK to commit, if you’re confident (which means you successfully built it in a chroot setup, and have done a reasonable copyright and license auditing). Likewise for package upgrades, except upgrades that trigger a lot of rebuilds (for example, upgrading GnuTLS or GLib). We have a mailing list for commit notifications (, so people can notice. Before pushing your changes, make sure to run git pull --rebase.

All commits that are pushed to the central repository on Savannah must be signed with an OpenPGP key, and the public key should be uploaded to your user account on Savannah and to public key servers, such as To configure Git to automatically sign commits, run:

git config commit.gpgsign true
git config user.signingkey CABBA6EA1DC0FF33

You can prevent yourself from accidentally pushing unsigned commits to Savannah by using the pre-push Git hook called located at etc/git/pre-push:

cp etc/git/pre-push .git/hooks/pre-push

When pushing a commit on behalf of somebody else, please add a Signed-off-by line at the end of the commit log message—e.g., with git am --signoff. This improves tracking of who did what.

When adding channel news entries (see Writing Channel News), make sure they are well-formed by running the following command right before pushing:

make check-channel-news

For anything else, please post to and leave time for a review, without committing anything (see Submitting Patches). If you didn’t receive any reply after two weeks, and if you’re confident, it’s OK to commit.

That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with.

In order to reduce the possibility of mistakes, committers will have their Savannah account removed from the Guix Savannah project and their key removed from .guix-authorizations after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process.

One last thing: the project keeps moving forward because committers not only push their own awesome changes, but also offer some of their time reviewing and pushing other people’s changes. As a committer, you’re welcome to use your expertise and commit rights to help other contributors, too!

Next: , Previous: , Up: Contributing   [Contents][Index]