Yocto Multiple Git Sources: Bind Each Repository to Its Own Revision

A recipe combines an application repository with a separate protocol repository. Updating the application revision unexpectedly changes the protocol checkout, or fetching the second repository fails with a revision that belongs to the first. One recipe now contains several source identities, and a single undifferentiated SRCREV is insufficient to explain them.

Use three independent mappings: URI name to revision, URI to checkout directory, and component names to a combined version string. Each mapping solves a different problem.

Bind each URI name to its own revision

Give the two Git entries distinct names, such as name=app and name=protocol. Assign their reviewed full commit identifiers through SRCREV_app and SRCREV_protocol. These illustrative names identify fetch components; they are not package names or machine overrides.

The examined BitBake revision-selection helper searches component-specific revision variables before falling back to the general SRCREV. For a named source it constructs keys containing an underscore, including SRCREV_app. Replacing that key with SRCREV:app would instead use override syntax and does not express this component-name lookup.

The helper also checks a revision supplied through a URI parameter against the selected metadata revision. Conflicting values are an error, so do not leave a stale rev= parameter beside a newly updated SRCREV_app and expect one silently to win.

Use bitbake -e sensor-suite to inspect the final SRC_URI and both component revision values, substituting the real recipe name. Check included files and append assignments when the value differs from the line being edited.

Give each checkout a deliberate destination

The Git fetcher reference defines destsuffix, whose default is git/. A URI name selects revision metadata; it does not automatically assign a different checkout directory.

For a side-by-side layout, the app entry could carry destsuffix=app and the protocol entry destsuffix=protocol, alongside their own names and branch parameters. With S = "${WORKDIR}/app", configure the application's build explicitly to find the sibling protocol directory. Do not assume S points at both repositories.

Specify the branch intended for each source unless the documented nobranch behavior is deliberately required. A revision-selection problem and an incorrect checkout layout can produce similar missing-file symptoms, but they require different fixes.

After unpacking, inspect the two directories independently. Confirm their HEAD identifiers and the path consumed by the build. A correct protocol checkout elsewhere in WORKDIR does not help if the build searches an old vendored directory beneath app.

Compose the revision display separately

The SRCREV_FORMAT reference explains how named source revisions are combined. For these component names, SRCREV_FORMAT = "app_protocol" expresses the desired composition.

This format does not assign either commit and does not control unpack locations. The examined fetch helper uses it when constructing a multi-source revision string; a missing format at that point raises an error. Including both names makes the string describe both components rather than hiding one behind a product version label.

Keep the full identifiers in the source configuration even when a displayed version abbreviates them. The Yocto SRCREV reference recommends a full revision identifier when a fixed revision is required without repeated remote tag resolution. A shortened display is not a replacement for that source selection.

Review a one-component update as a pair

For a proposed application-only update, compare the effective app and protocol revisions before and after the change. Then compare both unpacked HEAD values. The expected observation is that app changes while protocol stays at its reviewed identifier.

If both move, inspect shared fallback assignments or duplicated names. If the revisions are correct but source paths are wrong, inspect destsuffix and build-system directory arguments. If only the package's combined revision description is wrong, inspect SRCREV_FORMAT and the recipe's version integration.

Finally, exercise the interface between the two selected commits. Independent pinning makes their identities explicit; it does not establish that the chosen application and protocol revisions are compatible.