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 http://git-scm.com/
Git is included by default in CentOS-6 & -7 and is available from EPEL for CentOS-5.
The CentOS project hosts our sources at git.centos.org 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.centos.org
Git.CentOS.Org
Projects
Code at git.centos.org is organised into git repos, one per rpm or role. These git repositories are then organised into 'projects'. The main 'project' is called rpms/ and contains git repos for all the rpms we build and ship. You can view this project at: https://git.centos.org/project/rpms
Typically, every SIG would have its own project. This allows them to add in non rpm content (eg. test suites, or management interfaces, scripts, etc) within their own domain. SIGs would also typically have administration rights over these projects they own.
Git organisation
Git repositories, specially those that contain rpm content, are organised by branch names that map to CentOS Releases eg. branch name 'c7' would be where you will find content released into CentOS Linux 7. Similarly c5 and c6 branch names correspond to CentOS-5 and CentOS-6. There is usually no content in the MASTER or HEAD branches other than a readme indicating where to look for the actual code. When working with a SIG specific component, we recommend committing code into a branch that maps to the SIG name (or the SIGs project name on git.centos.org). This not only allows people to view and track on the code history they care about but it also allows people to create site-specific forks and branches without polluting the distro release tree.
Non Text Sources
We only checkin text sources into git. All non-text sources are extracted, hashed (sha256sum'd) and uploaded into their own lookaside cache at https://git.centos.org/sources/ 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 https://git.centos.org/sources/<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 get_sources.sh script.
get_sources.sh
Everyone considering consuming and contributing content to git.centos.org must first clone and setup the centos-common code, which is available at: https://git.centos.org/summary/?r=centos-git-common.git
The git command to clone this would be:
[user@host]$ git clone https://git.centos.org/git/centos-git-common.git
This git repository contains, amongst other things, the get_sources.sh 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).
Example workflow
Assume we want to work with the CentOS kernel sources.
[user@host]$ git clone https://git.centos.org/git/rpms/kernel.git cd kernel # let's work on the centos7 kernel [user@host]$ git checkout c7 [user@host]$ ~/bin/get_sources.sh # 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
Contributing code to existing Git repos
We prefer patches created using 'git format-patch' and sent to the centos-devel mailing list ( http://lists.centos.org/mailman/listinfo/centos-devel ). Using the above example of working with the kernel sources :
[user@host]$ git clone https://git.centos.org/git/rpms/kernel.git cd kernel # let's work on the centos7 kernel [user@host]$ git checkout c7 [user@host]$ ~/bin/get_sources.sh # 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 change' -a
Repeat the process for all the commits you want to get in, ideally doing one complete feature or change set in one commit - and split multiple features into their own commits. Its also a good idea to use verbs in your commit message, describing what you did. If the work corresponds to a bug report, please include that as well, using #<number> as the reference. Once all the commits are in place, you can create the commit tree into patch files like :
[user@host]$ git format-patch c7
You should now have files in the working directory named as 0001-<commit>.patch and 0002-<commit>.patch etc; These files should be emailed to the centos-devel list as attachments ( ie, not inline in the email body ). Include information about what change you are requesting and if needed include information on bugs.centos.org that points to the list archive page that has your email from http://lists.centos.org/mailman/listinfo/centos-devel.