Re: Understanding the git commits for Yocto and meta

Jim Abernathy

On Jan 28, 2012, at 6:25 PM, Bruce Ashfield wrote:

On Sat, Jan 28, 2012 at 9:51 AM, James Abernathy <jfabernathy@...> wrote:
While I've read enough to think I understand git, I get confused when it's
applied to real situations like Yocto.  If I look at the Yocto Development
Manual, Appendix A, A.5.2.4 Changing Recipes-kernel, It brings up some

1. The way I see it, when you guys commit something to the linux yocto
master or meta there is a commit string associated with that commit.  Not to
any certain branch of the git repository, right?

I'm not following your terminology. There's a git has that is used to
update the SRCREVs
for bitbake, but that hash is always on the meta branch. Bitbake likes
git hashes, but the
kernel build infrastructure talks branches .. since humans can
remember branches, but
not git hashes.

I'm sure I'm not using the terminology right because, I clearly don't understand the whole concept yet.  That light bulb has not gone on yet. :-)

Basically, I see from a user perspective that you start the process with creating a clone of the Yocto Project files repository, git://, and you also create a clone of the meta-intel BSP repository if you are working with the Intel board BSPs.  I have on occasion also cloned the Yocto Linux Kernel and poky extra so I could do the Appendix B example.  In the examples and my testing, I've always checked out the edison branch of both the yocto project files in the poky directory and the edison branch in the meta-intel directory.  So in my primitive  thinking, my branch is edison.  By examining Appendix B, I see where they checkout a branch of the Yocto Linux kernel called, common-pc-base, using the command, git checkout -b common-pc-base origin/yocto/standard/common-pc/base.  But once changes are made you commit those changes to the local bare clone that will be used in the build process.  So I think I see that to get the right versions of the Yocto Linux Kernel, I need to tell bitbake to use a particular branch called yocto/standard/common-pc/base.  I think the KMACHINE parameter does this in the Appendix B example.  However, in the App. B example, there is no talk about SRCREV anywhere.
Relating Appendix A recipes-kernel SRCREV to Appendix B example is a problem for me.

2.  So if I'm building an image for atom-pc using Edison branch, the first
SRCREV I'm interested in is yocto/standard/common-pc/atom-pc branch.  But
the commits I see at

are commits not associated with Edison, but Master, right?

They are all just commits on the board branch. edison has a snapshot
in time the SRCREV
that is used. Master marches on, but the commits that were current in
the timeframe of edison,
will always be there.

So here is a terminology problem in my mind.  yocto/standard/common-pc/atom-pc seems to be a branch in the meta-intel repository.  edison seems to be both a snapshot and branch of poky repository.???

For example, at ,, I see Poky listed. clicking on Poky,, I go to a summary page that shows edison as a branch of poky. If I look at the log and commit tabs on that page I see that Scott Rifenbark had a patch that got committed most recently in November:

author Scott Rifenbark <scott.m.rifenbark@...>2011-11-23 18:58:23 (GMT) 
committer Richard Purdie <richard.purdie@...>2011-11-25 15:26:48 (GMT) 

So that tells me that If I sticking to edison for everything related to poky, then I need to use this commit string to get the latest Edison Poky patches, Am I right???
Where do I put that or is the fact that I checked out edison branch and did a recent pull make me current with respect to poky???

So basically, in Appendix A Recipes-kernel section.  what exactly are the SRCREV statements telling Bitbake and why are there 2 of them.


3.  How do I find the commit string for a particular branch, like Edison,
for something like yocto/standard/common-pc/atom-pc?

I'm not following the terminology again. Maybe if you describe what
you are trying to
achieve ? git will tell you what branch has any commit .. just use git
branch --contains <hash>

4.  To me, branches are things like Edison, Bernard, etc.  But on the page:

yocto/standard/common-pc/atom-pc, master, and meta are all listed as
branches.  What is the difference??

edison and bernard are yocto branches. The kernel is a separate
repository and can actually be
used standalone (which I do). It has branches for it's meta data and
to isolate board changes.
A particular kernel repository is referenced by the yocto kernel
recipes. They are what follow the
yocto branches .. not the kernel itself.

I think I see part of my problem.  (Other than too much bourbon over the last 40 years)
The Yocto project (poky) repository has edison, bernard, master as branches of that repository. I need to keep that thinking separate from the meta-intel repository where edison and bernard are also branches.

Plus, the yocto linux kernel is yet another git repository which has branches like meta, crownbay, common-pc, etc??  did I get that right??  is this the only part that needs a SRCREV??

5.  The second SRCREV seems to be associated with meta.  How does that
relate to my whole confusion on branches.

A board build is composed of two things the meta data (configuration,
patches) that
describe the BSP and the actual code changes (the board branch).

So in the Appendix A example, which SRCREV is tied to what?  Below is the 1st SRCREV for the board branch(actual code changes)? and the Second one the Meta data?:
 COMPATIBLE_MACHINE_mymachine = "mymachine"
     KMACHINE_mymachine  = "yocto/standard/common-pc/atom-pc"
     KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"

     SRCREV_machine_pn-linux-yocto_mymachine ?= \
     SRCREV_meta_pn-linux-yocto_mymachine ?= \

6.  To me, if you are working with Edison and a particular BSP, then these 2
commit strings should be constant forever, right?

Yes, for the official / known BSP. If you do local work, you can of
course have your
own tree and advance both.



Thanks for taking the time to help me with this confusion.

Jim A

yocto mailing list

"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Join to automatically receive all group messages.