Bug 15197

Summary:	bitbake does not recognize that git-lfs is not installed when usehead=1 is used
Product:	[Build System, Metadata & Runtime] BitBake	Reporter:	tom.georgi
Component:	bitbake	Assignee:	Richard Purdie <richard.purdie>
Status:	ACCEPTED ---	QA Contact:
Severity:	normal
Priority:	Medium	CC:	ccasciato, konrad.scherer, poky.bs.watcher, poky.watcher, randy.macleod, sivakumar.bs, tom.georgi
Version:	unspecified
Target Milestone:	6.2
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description tom.georgi 2023-08-18 09:06:00 UTC

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.

Comment 1 Randy MacLeod 2023-08-24 15:05:00 UTC

Tom, Can you submit a patch?

Comment 2 Randy MacLeod 2023-09-28 15:04:16 UTC

Richard will try to make time for this bug in 5.0.

Comment 3 Siva Balasubramanian 2026-06-22 14:21:31 UTC

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.