I'm using Yocto 4.0, kirkstone.

We set
URI is git://dev.azure.com/PG-CT/PGLinux/_git/pg-linux;protocol=https;branch=pg-am57xx-ti-rt-linux-5.4.106

SRCREV="7818dfe57e1d1e2d2eaf039d1231560611811d67"

BRANCH="pg-am57xx-ti-rt-linux-5.4.106"

The DL_DIR contains above repo (git2/dev.azure.com.PG-CT.PGLinux._git.pg-linux) and above branch but just not the latest commit of this branch.

recipe linux-ti-staging-rt-5.4.106+gitAUTOINC+7818dfe57e-r7a.spark10: task do_fetch: Started

recipe linux-ti-staging-rt-5.4.106+gitAUTOINC+7818dfe57e-r7a.spark10: task do_fetch: Succeeded

there is only a few seconds. Another proof IMHO that there was no network access.

Fetch works properly if the repo is not present at all in the DL_DIR.

I also check if shallow clone is set: seems that this is not the case unless there is some other setting to consider.

bitbake virtual/kernel -e | grep ^BB_GIT_SHALLOW
BB_GIT_SHALLOW:pn-binutils="1"
BB_GIT_SHALLOW:pn-binutils-cross-arm="1"
BB_GIT_SHALLOW:pn-binutils-cross-canadian-arm="1"
BB_GIT_SHALLOW:pn-binutils-cross-testsuite="1"
BB_GIT_SHALLOW:pn-binutils-crosssdk-x86_64-spark-linux="1"
BB_GIT_SHALLOW:pn-binutils-native="1"
BB_GIT_SHALLOW:pn-glibc="1"

In addition I got this info from the internet:

Why do_fetch didn’t update the repo:
BitBake’s fetcher logic:

If the repo exists in DL_DIR and the SRCREV is marked as available (based on metadata), it skips network fetch.
It doesn’t verify the actual commit presence during do_fetch—that check happens in do_unpack.

So the 2-second fetch means it reused the cached repo without pulling new commits.

I wonder what it means "SRCREV is marked as available (based on metadata)". It's obviously not there.

Thanks a lot for your support.

Chris