git fetcher sanity check for matching branch and SRCREV

git fetcher sanity check for matching branch and SRCREV

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

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?

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: git fetcher sanity check for matching branch and SRCREV

[Richard Purdie]

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

Re: git fetcher sanity check for matching branch and SRCREV

[Nicolas Dechesne]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

On Wed, Dec 11, 2013 at 11:51 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

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

well, my 2 cents.. I think that keeping tags without a branch is a 'valid'
feature in git, whether we like it or not, and we won't be able to make
sure no upstream do that... so we probably need to support use of a tag in
SRC_URI as well, not just branches.

cheers

nicolas

[-- Attachment #2: Type: text/html, Size: 1376 bytes --]

Re: git fetcher sanity check for matching branch and SRCREV

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

On Wed, Dec 11, 2013 at 10:58:20PM +0000, Richard Purdie wrote:
> 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

yes we discussed this one in
http://lists.openembedded.org/pipermail/bitbake-devel/2013-August/003725.html
which I haven't finished yet, sorry :/

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]