Project:Toolchain/Patchsets with Git

This page describes in detail how the sys-libs/glibc patchsets have been migrated to Git. Hopefully we'll at some point use the same or a very similar system for all parts of toolchain (ie., gcc, binutils, ...).

Regular upstream development
The libc git repository has a master branch where current development takes place. On this master branch, releases are tagged as, e.g, glibc-2.26. From each release tag, a stable / backport branch starts with name release/2.26/master.

Upstream git repository:

Vendor branches and tags
The following branches and tags used to be in upstream git. Right now I am pushing them to a separate github repository, but I'll try to eventually get access to upstream git again.

Github git repository:

Gentoo has a vendor branch gentoo/2.26, which branches off at the upstream glibc-2.26 tag. On this branch the commits corresponding to Gentoo ebuild releases are tagged as gentoo/glibc-2.26-0, where in this case 0 is the patchset number. When upstream makes a new release, say glibc-2.27, a new such branch gentoo/2.27 shall be created starting at that tag, and the existing gentoo/2.26 head be rebased ont it to forward-carry Gentoo-specific patches.

Making patches
Making patches is easy; just add commits to one of our vendor branches as e.g. gentoo/2.26.

Usually they should be cherry-picked from the upstream stable branch release/2.26/master or the upstream development branch master. In rare cases it may also make sense to add more Gentoo-specific stuff.

Any commit where the commit message starts with [no-patch] will not generate a patch; this is useful for changes in the extra Gentoo files as e.g. the patchset generation script.

Making a patchset
This generates from the current head of gentoo/2.26 a patchset tarball named, and tags the current head of gentoo/2.26 as gentoo/glibc-2.26-1.


 * Please read the script before using it!
 * Make sure your gpg is working for the signed tag!
 * Any commit where the commit message starts with [no-patch] will not generate a patch.
 * Uploading the tarball and pushing stuff to git still must be done manually.
 * So far this infrastructure only exists for 2.26 (and 2.25 on my laptop); earlier branches on request.

Binutils
What's different?


 * The upstream release tags look like
 * Since there were irregularities in the tag naming, you can override them by creating a tag
 * The tarball contains the patches in a subdirectory "patch", not "patches"
 * The "development flag". Ugh...