On Wed, 2021-05-12 at 17:11 -0700, Andre McCurdy wrote: > On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin > <[email protected]> wrote: > > > > 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. > > None of the answers given so far seem very convincing...
I had a look at the code to try and remind myself why it is doing this. The best answer I found is that it does support filtered fetching of remotes, i.e. it can and will only pull the branch it wants/needs rather than a full repo clone. In the case of a small repo, it doesn't matter much. For a large repo it can make a significant difference to the speed. We also don't run "test" commands against the remote repo, we figure out what we want and then get it with small numbers of commands. Another reason we have the branch name is so that we can ls-remote the repo when using AUTOREV for SRCREV. We've tried to make it so that once a url is established in SRC_URI, you can make it use AUTOREV without changes to the url itself. The AUTOREV code path is in parsing which does mean we need to be efficient about the revision resolution. > If the git revision that a recipe wants is available on an unexpected > branch in the upstream repo then it's not really different from a tar > file being fetched from a mirror rather than whatever is in SRC_URI. > If we want the fetcher to fail as an indication that an upstream git > repo has renamed branches then don't we also want it to fail if a tar > file disappears from an upstream server? It seems odd that one should > be a fatal error and the other to be something we try to cover up and > hide from the end user. The fetcher is consistent. It will fail in both cases unless a source mirror is available with the sources in. If a source mirror is available, it should work. > Anyway, for recipes which don't explicitly specify a branch in SRC_URI > it would seem quite reasonable for the fetcher to check what the > default branch is set to in the upstream repo and search for the > required git revision in that branch (rather than rely on a hardcoded > default of "master" as we do now). Going forward, there's going to be > less standardisation on what upstream repos call their default branch, > so we're either going to have to explicitly specify a branch in more > and more recipes or teach the fetcher to automatically figure out what > the default branch in the upstream repo is. Is explicitly specifying the branch along with the repo url such a big problem? We already have to provide the url, it isn't like we guess that too. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151696): https://lists.openembedded.org/g/openembedded-core/message/151696 Mute This Topic: https://lists.openembedded.org/mt/82782995/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
