[meta-ti] objections to replacing git SRCREV tag names with actual hash IDs?

[Denys Dmytriyenko]

On Thu, Jan 31, 2013 at 06:58:37AM -0500, Robert P. J. Day wrote:
> 
>   surely, some of you saw this discussion on the oe-core list last
> night, but would there be any objection to replacing the small number
> of git SRCREV settings of tag names with their actual hash IDs?  the
> motivation should be obvious -- avoid network traffic to parse those
> tag names, even when that recipe isn't even being used in the image
> being built.

Yes, I've had occasional issues with "git ls-remote" during parse time on 
resolving those tags into commit IDs and was planning on eventually replacing 
them.


>   here's the entire list of SRCREV assignments in all of meta-ti, so
> you can see there are only four related to git tag names:
> 
>   i'm currently spending some time at a site that doesn't allow git
> access so those tag names are fatal for doing any sort of OE building.
> and only one of those appears to *prefer* to use the tag name --
> 
> recipes-kernel/linux/linux-keystone_3.6.6.bb:
> 
> # The tree tends to rebase, use literal stable tags
> SRCREV = "DEV.MCSDK-03.06.06.07"

And that's what mainly was stopping me from doing it already...


>   but, really, you shouldn't be rebasing published commits, anyway.
> so ... thoughts?

And _we_ are not rebasing published commits, but there are some things _we_ 
cannot control, unfortunately. I can talk to other teams to ask them to stop 
rebasing their trees, but in some cases the tree is specifically meant to be 
staging and is supposed to rebase from release to release. There are ways to 
do it differently, so I'll talk to those teams and see what we can do...

-- 
Denys