[OE-core] Why to make branch info is mandatory for non-master commit with latest bitbake

[Richard Purdie]

On Fri, 2014-03-14 at 12:50 +0100, Detlev Zundel wrote:
> 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.luo at 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".

Imagine you set your recipe to some invalid SRCREV. It was possible that
the fetcher would notice it was missing and attempt to fetch it from
upstream (so far so good), then silently continue the build even though
it had been unable to find the revision.

I think we can agree that is bad, if it can't find something specified,
it should error. This is why we added the extra checks to ensure that
the revision really does exist after we fetch from upstream.

> 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?

This isn't a workaround, it fixed a very specific and nasty issue as
described above.

Cheers,

Richard