On Mon, 2016-03-28 at 15:58 -0400, Cliff Brake wrote:
> On 03/26/2016 03:41 AM, Richard Purdie wrote:
> > HEAD is a revision, not a branch and the fetcher became a bit more
> > picky about that difference. Your local tree must have HEAD on some
> > branch which would usually be master so setting branch=master is
> > likely
> > correct, or don't set that parameter at all? master isn't just a
> > remote
> > thing.
> >
> > The piece which says "use the HEAD revision" is the SRCREV =
> > "${AUTOREV}" line.
> >
> > Cheers,
> >
> > Richard
> >
> We typically set up our projects to use git submodules, such that the
> top level
> calls out a set of submodules which are the actively developed
> applications and
> other bits in the system. These submodules are externalsrc trees for
> bitbake,
> and include a bitbake recipe (bitbake recipe is embedded directly in
> source
> code). Sometimes these submodules/externalsrc trees track branches
> (typically
> release-xyz, or develop-xyz), but almost never master. Sometimes
> they may be at
> a tagged version that is not at the HEAD of a branch. In the end, I
> want to be
> able to build exactly what is in the externalsrc directory, and
> accurately
> include the git version in the PV. Branches/tags may change at any
> time and I
> don't want to have to edit the recipe every time this happens.
>
> Repo might be used in a similar fashion to manage a tree of
> components that get
> built. What we are trying to avoid is having to edit the git version
> in the
> recipes to lock down versions for a set of components for a build --
> git
> submodules or repo work much better for doing this.
>
> I tried nobranch=1;rev=HEAD, but then that conflicts with ${AUTOREV}.
Did you just try nobranch=1 and leave rev to get set from SRCREV?
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
