And by the way, another reason to check that revision is linked to a branch is when SRCREV is updated - we need some reassurance that the updated SRCREV comes from the same branch as previous SRCREV, or that if the branch has changed, it's explicitly visible in the diff and explained in the commit message.
Alex On Wed, 12 May 2021 at 23:17, Alexander Kanavin <alex.kana...@gmail.com> wrote: > On Wed, 12 May 2021 at 22:44, Colin Walters <walt...@verbum.org> wrote: > >> On Wed, May 12, 2021, at 4:40 PM, Alexander Kanavin wrote: >> > For ostree, yes: >> > http://git.openembedded.org/meta-openembedded/log/?h=master-next >> > >> > For the generic case, no. It's not a good idea to start guessing what >> > the upstream did. >> >> What is the goal of the `branch=` specification? I can understand it >> being *informative* for humans specifically when things like >> non-master/main branches e.g. `release-4.x`, `lts-`, `stable-` etc. are >> involved. >> >> But why is bitbake explicitly checking it? Is it to validate what the >> human expressed, or is it to try to cover some security aspect? Something >> else? >> > > To ensure the specified revision is actually linked with the specified > branch, and not just free-floating, and catch branch renames, deletions and > force pushes. You can override that behaviour with nobranch=1, at your own > risk - free-floating revisions can be 'garbage collected'. > > Yes, it's annoying when the upstream renames branches, but it's no > different than upstreams clearing up old tarballs, or disappearing > altogether. Ensure you have proper download mirrors. > > Alex >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151680): https://lists.openembedded.org/g/openembedded-core/message/151680 Mute This Topic: https://lists.openembedded.org/mt/82782995/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
