On Thu, 2021-05-13 at 14:25 +0000, Peter Kjellerstedt wrote: > > 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. > > Wouldn't using "HEAD" instead still maintain the same properties as using > "master", but with the added benefit that it just works for repositories > that decide to use some other branch than "master" as their main branch? > E.g., using `git clone --single-branch` (without -b) fetches HEAD and > whatever branch it references, which is what we want, is it not? > >
See the ;usehead=1 uri option. > > > One problem I have with the way the branch is specified is that it is a > URL parameter. This means that when I want to add a bbappend to specify > another SRCREV, it becomes problematic if that SRCREV is on a different > branch than what the base recipe uses. It basically means one has to > use SRC_URI_remove to remove the original URL for the repository, and > then add a new version of the URL with SRC_URI_prepend. This obviously > is unrelated to the discussion about main vs. master, but I would very > much like to see a new variable, e.g., SRC_BRANCH, being added to > complement SRCREV. There is an edge case for recipes that use multiple > Git URLs in the SRC_URI, but they are rare, so having to specify the > branch using the branch= parameter in the unlikely event that those > repositories need different branches should be acceptable. This is getting a little sidetracked from the original discussion. I believe anyone changing branch urls like that can probably parameterise the url themselves and there isn't generic demand to add more complexity... What I do suspect we need is the ability to change url parameters in mirroring url mappings, which could possibly help for a few of these cases too. There is an open bug for that, I keep meaning to try and sort it out. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151726): https://lists.openembedded.org/g/openembedded-core/message/151726 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] -=-=-=-=-=-=-=-=-=-=-=-
