Bug 15558

Hi Janik,

I'm currently looking into this bug, but I haven’t been able to reproduce it on my side.
Could you share a minimal example that reproduces the issue?

I tried adding a subpath parameter to a Git-enabled recipe, with a specific SRCREV.
Looking into tmp/work/<arch>/<package>/<version>/<subpath>, I do see the files from the subpath as they were in the commit specified by SRCREV.

However, when I run git log inside that folder, it shows the latest commit of the branch instead.
Also, git status reveals that all files except the subpath are marked as deleted.
Could this be the source of confusion?

Can you confirm whether you observe the same behavior? Or do you see the subpath files as they are in the latest commit of the branch?

I can try doing some Git magic to show the log from the specified commit and clean up the staging area, resulting in a more "clean" directory — especially in a devtool environment. Would that be less confusing?
Additional details:

To perform the partial checkout, the Git fetcher uses low-level plumbing commands: git read-tree and git checkout-index.
These commands do not update HEAD, which is fine when just building with BitBake.
However, it becomes quite confusing when using devtool modify, as you’ve likely seen.

@Richard – what do you think about switching to git sparse-checkout instead?
It was introduced in Git 2.25 but is still marked as an experimental feature even in recent versions [1].
Personally, I think we should hold off on switching to it — at least for now.

Cheers,
Julien

[1] https://git-scm.com/docs/git-sparse-checkout/2.42.0

Hi Julien

This is in fact an interessting theorie. We build our software inside of yocto and build in the commit hash which is then shown on a display. This is how I found the "bug". If the git tool reports the commit hash of the latest commit, it's possible, that this one was build in instead of the "real" one which is in the SRCREV. Switching away from the subpath fixed then the problem.

I will verify if this is correct. You will hear from me.

Greetings Janik

Hi Julien

I was able to confirm, what you explained. When using the subpath option, the commit hash git reports don't change, but the status of the folder is the one expected from the commit hash of the SRCREV. So I confirm your observed behavior.

For me personally, I would also not switch to the experimental feature of git. I'm also hesitating in changing the behavior with some "git magic" as you described. A `git reset --soft` to the specific commit works, but still shows all the other files as deleted with git status, which still could be confusing. What could maybe help, is a disclaimer in the git fetcher section of the BitBake manual, which says that the HEAD don't get updated.

My conclusion would be: Some information in the documentation could help preventing others running into the same confusion as I did, but otherwise I think we could close the issue.

Greetings Janik

Antonin,

Is there a code changed needed or only docs ?

It sounds like the behaviour is correct but the head revision being reported by git is confusing. At the very least we need to document that so copy Antonin for that piece.

I'm not sure if it is possible to change the fetcher code to improve things or not. We certainly don't want to use experimental git features though.

Patch sent on bitbake list to document this behavior:
https://lore.kernel.org/r/20260326-add-subpath-warning-v1-1-ece919e8779a@bootlin.com

Patch merged: https://git.openembedded.org/bitbake/commit/?id=7c42f89fb7d5e9e19434d199415738e0ad79e79c