git-lfs was not installed. The error should have been caught by poky and throw an error message accordingly. The method contains_lfs() under the file bitbake/lib/bb/fetch2/git.py sets the variable refname to the respective specified branch. Since in our case no branch name but usehead=1 is specified, this is empty for us, whereby the subsequent command does not find any git-lfs files. Bitbake has an instance variable `revision` in this class, which resolves all names as revisions. When specifying usehead=1, HEAD will be resolved as a revision as well. Instead of using `ud.branches` as refname, `ud.revisions` could be used in this method to solve the bug. Since in our case the lfs files are local and not downloaded through the network, they can also be fetched in a later step. However, if the data was downloaded through the network, then this would lead to an error. For this reason, we have come to the assumption that this is a bug in BitBake.
Tom, Can you submit a patch?
Richard will try to make time for this bug in 5.0.
This looks fixed on current master, as a side effect of: commit 2515fbd10824005fa7f34e87706000c079920366 "fetch: Drop multiple branch/revision support for single git urls" Richard Purdie, 2025-03-18 That commit collapsed ud.branches/ud.revisions (dicts) down to singular ud.branch/ud.revision. As part of it, _contains_lfs()'s refname is now derived from ud.revision instead of ud.branches[name]: cmd = ud.basecmd + ['grep', '^[^#].*lfs', ud.revision + ':.gitattributes'] ud.revision is always a resolved SHA, including when usehead=1 is set (HEAD resolves to a real revision during urldata_init), so the original problem - empty branch under usehead=1 causing the LFS check to silently no-op - no longer applies. Confirmed by replaying the old refname = ud.branches[ud.names[0]] logic against a local repo with LFS-marked .gitattributes: it fails with "fatal: ambiguous argument ':.gitattributes'", swallowed by the existing except (FetchError, ValueError): pass, so _contains_lfs() returns False. The current ud.revision-based version returns True against the same repo.