Hi Richard, sorry to jump in so late, but I just realized that this "small" change has some impact also on our ELDK recipies, so I would really like to understand where the change comes from and why we couple a persistent specification (commit ID) with a transient specification (branch name). With all my previous git experience, this looks at least somewhat strange.
> On Mon, 2013-12-23 at 06:41 +0000, > zhenhua....@freescale.com wrote: >> Previously the branch name doesn't need to be defined when a >> non-master branch commit is referred in recipe, this has been changed >> in latest bitbake. >> >> Is this an intentional change? May I know the reason of the change >> if it is intentional? > > It was intentional and was triggered by this change: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f19546e02d3318ee69fd0c34e21aa97b74c987ec > > which is a sanity test added to fix certain failure cases where a given > revision wasn't on a specified branch. > > The bug was nasty since the fetcher was hitting the network in cases it > shouldn't have been when a branch wasn't specified. I looked at the provided link but I'm not certain that I understand the problem nor the fix for it. As far as I can make out, the "failure mode" was likely a specified commit ID that was not available in the local downloads. As a consequence, the fetcher then hit the network and tried to find this (locally not existing) version in the upstream repository. So very likely, the "failure" was that a network access happened at all, correct? So the "failure" is much more a "we don't want network access at all under certain circumstances". If this is correct, then I see how the fix prevents this by effectively limiting the selectable commit IDs to the _existing_ commits in one branch. But doesn't that prevent me from specifying a commit-id in an upstream branch "later" then what I have available locally in that old branch state? I.e. should we rather find a way to say "no downloads are allowed at all" rather than adding this workaround? Of course we can fix all our recipies, but I'd really like to understand why we are doing this. Thanks! Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
