linux/poky.git/bitbake/lib/bb/fetch2/git.py, branch yocto-3.1.7

bitbake: fetch/git: download LFS content too during do_fetch

2021-02-05T12:18:38+00:00

Insert an explicit pass to fetch all blobs needed by Git LFS, during the fetch() function. This avoids the default behavior of Git LFS to wait until 'git checkout' to begin downloading the blobs pointed to by LFS records. Network access is not allowed at that point in the recipe's lifecycle. [YOCTO #14191] (Bitbake rev: 2351b496bb63b96920d4ae67bec816f00d510df2) Signed-off-by: Matt Hoosier Signed-off-by: Richard Purdie (cherry picked from commit 0efac66043662e7a2027192f50e92e982db2ba1c) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

2021-02-05T12:18:38+00:00

Function "contains_lfs" was only looking at the master branch when searching for LFS content. LFS may be configured in specific branches only, so we need to use the correct branch. (Bitbake rev: 274f790ac9161187810df3242d3570261e407b11) Signed-off-by: Mauro Queiros Signed-off-by: Richard Purdie (cherry picked from commit 4fa67c2af830035a1ddedc14592ee25a15ebff22) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: git.py: LFS bitbake note should not be printed if need_lfs is not set.

2021-02-05T12:18:38+00:00

The message "Repository %s has LFS content but it is not being fetched" was being printed, even when Git-LFS was available and "lfs=1" was set. In those situations, we want to fetch LFS content, so that message would not make sense. (Bitbake rev: 2795c6150c0b3218716195c0d10ff2843b1ef695) Signed-off-by: Mauro Queiros Signed-off-by: Richard Purdie (cherry picked from commit 45028dfda5a29a34ab408cb3f11d72ae17963340) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: git.py: skip smudging if lfs=0 is set

2021-02-05T12:18:38+00:00

Git-LFS objects were being fetched even when lfs=0 was not set. This patch disables LFS smudging when lfs=0. That way, only the LFS pointers are downloaded during checkout. (Bitbake rev: 3d09608cabd404733b95ea92d5b00830ded77834) Signed-off-by: Mauro Queiros Signed-off-by: Richard Purdie (cherry picked from commit 646d86df7de774255246a3d7051c308e43eb257d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bitbake: fetch/git: add support for SRC_URI containing spaces in url

2020-10-13T08:40:10+00:00

Microsoft's TFS VCS system allows for spaces in a git repository url. An example of a valid url is: ssh://tfs-my-company.org:22/tfs/My Projects/FooBar This commit adds support for such urls by implementing two changes. Firstly, when bitbake makes a git command line call the url is surrounded by quotes so that the url, regardless of spaces, is treated as one argument. Secondly, additional parsing of various filepath variables, which are based off of the url, are now completed with any spaces in the url replaced with underscores. (Bitbake rev: c4a51b7f4fd8a3c7d63c184675c014ec955d2606) Signed-off-by: Charlie Davies Signed-off-by: Richard Purdie (cherry picked from commit eb38b6f0935763f7ba19e5618f376fcae1dac41a) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: fetch2: Change git fetcher not to destroy old references

2020-07-19T15:22:12+00:00

It looks like we're about to see a lot of changes in branch names in repos. If we have the prune option here, those old names are lost, the changes propagate to our source mirrors and our old releases break. We have the force option so any replaced references should be replaced, its only orphaned branches which will now be preserved. I believe this behaviour will cause us fewer problems given the changes that look likely to happen. (Bitbake rev: 6e527ea72b0816bf5f454473faf6523c365daa18) Signed-off-by: Richard Purdie (cherry picked from commit 820ab886e79eea516560c0c008e4cf059c6e11a3) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: fetch2/git: _revision_key: collapse adjacent slashes

2020-01-19T13:31:05+00:00

>From a SRCREV caching point of view, there is no reason to treat the following upstreams as different: SRC_URI = "git://github.com/file/file.git" SRC_URI = "git://github.com//file/file.git" (Bitbake rev: 425e21c14955dd38868c6e97637df3bbe0f89fac) Signed-off-by: Chris Laplante Signed-off-by: Richard Purdie

bitbake: lib: amend code to use proper singleton comparisons where possible

2020-01-19T13:31:05+00:00

amend the code to handle singleton comparisons properly so it only checks if they only refer to the same object or not, and not bother comparing the values. (Bitbake rev: b809a6812aa15a8a9af97bc382cc4b19571e6bfc) Signed-off-by: Frazer Clews Signed-off-by: Richard Purdie

bitbake: fetch2/git: fetch shallow revs when needed

2019-10-28T05:31:53+00:00

When bitbake determines if a git clone needs updating, it only checks for the needed srcrevs, not the revs listed in BB_GIT_SHALLOW_REVS, which will fail if using shallow and the needed rev was added to the upstream git repo after a previous fetch. Ensure that we also check for shallow revs. [YOCTO #13586] (Bitbake rev: 93b65e3c6ca64f644946953980595c44fbbcc748) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: fetch2/git: refactor check for git-lfs command

2019-09-27T12:02:19+00:00

Refactor the git-lfs checking: this means both clearer code in the download() function and allows unit testing to monkeypatch the functionality. (Bitbake rev: 33cf9172ded50a869f7201ba463ab9ecc69b8252) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie