Git is the version control software of choice for us here at the CentOS Project. If you are new to this, there are some great resources including getting started guides at

Git is included by default in CentOS distribution.

The CentOS project hosts our sources at and we consider this to be the canonical upstream for the project. Various efforts, as a part of the project, might choose to also mirror their content in other places like Github. However all release content must be built from, tested via and curated at


Git server[s] is now running on Pagure and is also replicating branches between CentOS and Fedora. Both pagure instances are part of a repoSpanner cluster:

How does that cluster work? For some projects/git repositories, branches that are considered authoritative from one instances are replicated in the cluster, and so appearing at the other pagure instance. That also means that, because each pagure instance still uses its own authentication system, both pagure instances ( , have some branches protections in place. Branches that are protected :

See below how you can automatically be granted access on some branches, based on your SIG group membership (with your ACO account)

TIP: A dedicated talk about this topic was given at the CentOS Dojo in 2019. You can still view that presentation online


The pagure instance uses now ACO to grant you access to some git projects hosted on this server. That means that you need first to have your ACO account (feel free to create one yourself on the ACO portal if you don't have yet your CentOS account.

During your first login on, your settings from your ACO account will be synced over :

Usage script

Everyone considering consuming and contributing content to must first clone and setup the centos-common code, which is available at:

The git command to clone this would be:

[user@host]$ git clone  

This git repository contains, amongst other things, the script. This script, when run from a git checkout for an rpm git repo will parse the non-text-sources metadata file, and download the relevant files, setting up the SOURCES/ directory. You may want to create a symlink to this script from ~/bin (see the example session below).

Assume we want to work with the CentOS kernel sources.

[user@host]$ git clone ; cd kernel
# let's work on the centos7 kernel
[user@host]$ git checkout c7 
[user@host]$ ~/bin/
# switch to the local tree to edit
[user@host]$ git checkout -b my-kernel
# make edits to SPEC file, etc
[user@host]$ git commit -m'my local changes' -a
# ensure we can create a srpm
[user@host]$ rpmbuild --nodeps --define "%_topdir `pwd`" -bs SPECS/kernel.spec
# if that works,
[user@host]$ rpmbuild --define "%_topdir `pwd`" -ba SPECS/kernel.spec 

TIP: If you're only interested in one specific branch, you can just clone/retrieve that branch : git clone -b c7 --single-branch

End user

If you just want to download git repositories and/or sources, you can (anonymously) use the method described above.

Contributor / SIG maintainer

You already have an ACO account and are part of a SIG ? Then for each git repository under the /rpms/ namespace, you have already RWC to some branches. There are automatic ACLS for SIGs, and by default it goes like this :

The '*' for c* suffix means c6, c7 or soon c8

The '*' for the suffix is whatever you want in your SIG prefix name

Example : If you're member of the SIG-cloud group , you automatically have push rights to the following branch : c7-sig-cloud-rdo-queens

Non text sources (aka '''lookaside cache''' content)

We only checkin text sources into git. All non-text sources are extracted, hashed (sha256sum'd) and uploaded into their own lookaside cache at They are organised into groups that map to the branch of git to which they apply and are further grouped into the git repos to which they belong. The fully qualified path to those non-text-sources would then be<git repo name>/<branch name>/

Note that there is a special case for zero byte files, that are neither checked into git nor pushed into lookaside. These files are however still tracked and reproduced via the non-text-sources metadata file.

Every git repository has one of these metadata files named .<git reponame>.metadata and hosted in the root directory of the git checkout/branch. This file is used to map the sha256sums to their full filenames and are consumed by the script.

Getting sources

See the script describe above

Pushing sources

You can already push some sources directly, based on your group membership. Let's assume that you're member of the SIG-Cloud group, you can then push to <git repo name>/<branch name>, and so like c7-sig-cloud-rdo-queens (same principle as for the Git branches that your membership grant you RWC rights to)

All uploads to /sources/ are controlled by x509/TLS cert that you are already using for CBS/Koji builds

While a new tool called centpkg will be developed/used in the future, you can already use a curl wrapper tool called "lookaside_upload". You can find this tool in the centos-git-common git repositoriy also mentioned above.


You need to call the script like this : ./lookaside_upload -arguments

        -f : filename/source to upload (required, default:none)
        -n : package name for that source (requred, default:none, example "httpd")
        -b : "branch" where to upload to (required, default:none, example "c7-sig-core")
        -h : display this help

Notifications from

Message Broker (MQTT)

All activity happening on (public) git repos hosted on will trigger a mqtt notification (message payload) posted to our dedicated MQTT broker hosted for this on

How can you subscribe to that MQTT broker (if you want to automate some workflow) ? The only requirement is to trust our ACO ( CA cert and also to have your TLS cert from ACO. All those steps are done automatically through centos-cert (from centos-packager, see

From that point, you can use your MQTT client of choice (mosquitto_sub from mosquitto pkg, or python-paho-mqtt for python client, etc) and point to

Simple example with mosquitto_sub :

mosquitto_sub --cafile ~/.centos-server-ca.cert --cert ~/.centos.cert --key ~/.centos.cert -h -p 8883 -t -v

The message payload is a json that you can decode, and the topic is automatically created by pagure when pushing mqtt notifications.


There is currently no way to get emails notifications for *all* repositories and so get mails notifications for git push operations. Should you still need this, consider instead the MQTT broker method, or if enough people would like this, we can also eventually create a bridge that would post all that to a dedicated mailing-list hosted on (nothing discussed nor decided so far - just an idea)

Sources (last edited 2019-04-11 17:37:05 by FabianArrotin)