Re: [OE-core] git fetcher sanity check for matching branch and SRCREV

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2013-12-11 at 23:51 +0100, Martin Jansa wrote:
> I understand and support reasons behind recently added commit
> "fetch2/git: Add sanity check to ensure we really did fetch the correct
> revisions"
> 
> but there is at least one corner case which IMHO isn't supported now, in
> meta-webos we have yajl recipe with:
> 
> # corresponds to tag 1.0.12
> SRCREV = "17b1790fb9c8abbb3c0f7e083864a6a014191d56"
> SRC_URI = "git://github.com/lloyd/${PN}"
> 
> the problem is that 17b1790fb9c8abbb3c0f7e083864a6a014191d56 exists only
> in 1.0.12 tag and not in any branch
> 
> OE @ ~/webos/projects/yajl $ git branch -a --contains
> 17b1790fb9c8abbb3c0f7e083864a6a014191d56
> OE @ ~/webos/projects/yajl $ git tag --contains
> 17b1790fb9c8abbb3c0f7e083864a6a014191d56
> 1.0.12
> 
> There is "1.x" branch which contains parent of
> 17b1790fb9c8abbb3c0f7e083864a6a014191d56 but is missing this one commit.
> 
> Unfortunately we cannot "disable" this check by explicitly setting empty
> branch or setting tag=1.0.12
> 
> I can ask yajl owner to push that one missing patch to 1.x branch, but
> there were no changes in last 11 months so I don't know how responsive
> he will be and there could be similar case in different recipes where
> the upstream could be completely gone.
> 
> As side note, should bitbake do the same check when tag=foo is
> specified?

This is an interesting corner case. I have this patch lying around which
fixes the issue where a given tag is only available in specific
branches:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=d211662ca92ee084c0c4a3d343e0b1f28ab853ac

however that won't help this case. There is also an issue where the
ls-remote command can match multiple branches/tags since its unanchored:

git ls-remote X foo

refs/heads/foo
refs/heads/broken/foo
refs/tags/foo
refs/tags/broken/foo

All things considered the check is proving useful as its finding some
real issue however we have a few corner cases to iron out...

Cheers,

Richard