Git repositories

One of the most commonly used source control management systems in use is Git. BitBake has a solid support for Git, and the Git backend is used when the do_fetch task is run and finds a git:// URL at the SRC_URI variable.

The default way for BitBake's Git backend to handle the repositories is to clone the repository into ${DL_DIR}/git2/<git URL>. For example, check the following quote from the linux-firmware_git.bb recipe found in meta/recipes-kernel/linux-firmware/linux-firmware_git.bb inside Poky:

SRCREV = "a61ac5cf8374edbfe692d12f805a1b194f7fead2"
...
SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git"

Here, the linux-firmware.git repository is cloned into ${DL_DIR}/git2/git.kernel.org.pub.scm.linux.kernel.git.firmware.linux-firmware.git.

This directory name is chosen to avoid conflicts between other possible Git repositories with the same project name. The SRCREV variable is used by the do_fetch task to ensure the repository has the required Git revision and forces an update in case it does not; it's used by the do_unpack task to set up the working directory in the required source revision.

When the SRCREV variable points to a hash that's not available in the master branch, we need to use the branch=<branch name> parameter as follows: SRC_URI = "git://myserver/myrepo.git;branch=mybranch". In cases when the hash used points to a tag that is not available on a branch, we need to use the nobranch=1 option as follows: SRC_URI = "git://myserver/myrepo.git;nobranch=1".

The remote file and the Git repository are the most commonly used fetch backends of BitBake. The other source code management support systems vary in their implementations, but the general ideas and concepts are the same.

Table of Contents for Git repositories

Create new playlist

Sign In

Sign Up

Table of Contents for
Git repositories