On Tue, 29 Jan 2013, Martin Jansa wrote:
... snip ...
> It would be better to change SRCREV to hash corresponding to that
> tag and move tag only to comment above SRCREV. Such patch could be
> applied in upstream...
which brings up a larger issue ... what is the *preferred* way of
doing this if one was writing a style guide? i understand developers
might like to set git SRCREV variables to meaningful tag names but, as
i've learned, that really screws up the possibility of building with
no network. as it is, quite a few recipes set SRCREV to a hash ID for
*precisely* that reason and, in a short comment above (as you say),
mention the tag it corresponds to.
which brings me to what caused this annoyance in the first place --
the meta-ti layer, which has only four recipes that use
SRCREV = <tag name>
so it wouldn't be that hard to submit a patch to adjust those, but
then there's this in
meta-ti/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"
uh ... correct me if i'm wrong but isn't it in unspeakably bad taste
to rebase commits that have already been published?
in any event, can it be considered bad form to set SRCREV to git tag
names? thoughts?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
