Git Overview Screencast

This screencast (use Firefox to view the screencast) provides an overview of the Git version control system.  There are 3 features of Git that are especially interesting:

  1. many repositories (vs. one large repository)
  2. distributed development
  3. cheap branches

The fundamental driver for better tools is increasing system complexity.  More and more we are required to manage and integrate more third party software, work in distributed teams, and more effectively re-use the software we do have.  Git is a tool that helps you accomplish these goals.


Qt Creator for C/C++ development

Recently, I’ve been evaluating Qt Creator for general C/C++ development.  I’m currently involved in the development of a rather large C++ application that is approaching 200,000 lines of code and 1000 source modules.  In the past, I’ve typically used Vim for editing, and Eclipse as a gdb front-end when needed.  Qt Creator is a rather new tool developed by Nokia’s Qt team.  What initially attracted my attention was that one of the reasons the project was started was no existing tools effectively handled the Qt codebase, which is quite large.  Things I like about Qt Creator:

  • it works fairly well with any C++ Make based project.  This includes projects built with autotools as well as the Qt Qmake build system.
  • easy to import existing projects
  • it is very fast.  Indexing 200,000 lines of code happens in around a minute or so.
  • Provides a Vim compatibility mode that actually works
  • provides fast methods for finding files, symbols, and seeing where symbols are used
  • did I mention yet it is fast?

I also recorded a screencast that demos Qt Creator with a large project (can be viewed in firefox).  As always, I’m interested in what others find interesting in this or other tools.  Future efforts will be to use Qt Creator to build and remotely debug ARM binaries — I am interested in what others have done in this regard.

If you do try Qt Creator, I recommend the latest pre-release snapshot.


Git submodules: what to do when you commit to (no branch)

When using git submodules, eventually you’ll run into a situation where a workspace has checked out a submodule as (no branch), and you unknownly make modifications and commits to (no branch).  Now what?  It turns out Git has a very useful feature named reflog.  Reflog keeps a local time based log of all activity.  That means that as long as you do not garbage collect your workspace, you can go back to any point in time and get any commit that was made.  This is useful in a number of scenarios, but lets consider the case where we made two commits to a submodule in the (no branch) state.  We are then ready to push our changes to the upstream repo and we get:

cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git push bec HEAD
error: unable to push to unqualified destination: HEAD
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to ''

If we do a git log, we find we are on the infamous (no branch).

cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git branch
* (no branch)

At this point we may wonder what to do.  How do we get these changes onto the master branch?  Using git reflog, we can view all commits and changes to our local repository based on time.

cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git reflog
6d195b3 HEAD@{0}: commit: add recipe for qt-embedded image
4cf1bd6 HEAD@{1}: commit: add touchscreen utilities
bcc673c HEAD@{2}: checkout: moving from master to bcc673c9824e916a7ec6c04f60a17116af539423
56d9def HEAD@{3}: commit: add more features
5286f87 HEAD@{4}: commit: rename debug image
90896de HEAD@{5}: pull : Fast-forward
5cc3f3b HEAD@{6}: checkout: moving from 90896deb2a25f0d40b1e6305a0ad994f932f22d8 to master
90896de HEAD@{7}: checkout: moving from master to 90896deb2a25f0d40b1e6305a0ad994f932f22d8

Git will keep our keeps commits to (no branch) even though we might switch to another name branch.  And using git reflog, we can easily find these commits and merge them to the master branch.

cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git checkout master
Previous HEAD position was 6d195b3... add recipe for qt-embedded image
Switched to branch 'master'
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git reflog
56d9def HEAD@{0}: checkout: moving from 6d195b3909553b04cba3d3ac182076a2c6b866b2 to master
6d195b3 HEAD@{1}: commit: add recipe for qt-embedded image
4cf1bd6 HEAD@{2}: commit: add touchscreen utilities
bcc673c HEAD@{3}: checkout: moving from master to bcc673c9824e916a7ec6c04f60a17116af539423
56d9def HEAD@{4}: commit: add more features
5286f87 HEAD@{5}: commit: rename debug image
90896de HEAD@{6}: pull : Fast-forward
5cc3f3b HEAD@{7}: checkout: moving from 90896deb2a25f0d40b1e6305a0ad994f932f22d8 to master
90896de HEAD@{8}: checkout: moving from master to 90896deb2a25f0d40b1e6305a0ad994f932f22d8
cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git merge 6d195b3
Updating 56d9def..6d195b3
 recipes/images/       |   38 +++++++++++++++++++-----------
 recipes/images/ |    8 ++++++
 2 files changed, 32 insertions(+), 14 deletions(-)
 create mode 100644 recipes/images/

At this point, the changes have been merged to the master branch, and we can now push to our public repository:

cbrake@happy:/scratch/oe/oe-build-overo/openembedded.custom$ git push bec HEAD
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (10/10), 1.13 KiB, done.
Total 10 (delta 3), reused 0 (delta 0)
   bcc673c..6d195b3  HEAD -> master

Git reflog can also be used to restore commits that you decided at one point to throw away with “git reset –hard HEAD~2”, etc.  As long as you don’t garbage collect the repo, they are simply dangling state and always still exist.  This is just another example of the ways git can be very confusing, but also very powerful if you understand how it works.

This screencast covers the operations in this article.


Installing OMAP3 images on a SD card

This article and screen-cast is a continuation of that last couple posts describing the BEC OE build template.  The purpose again for a build system is to automate tedious manual tasks, and in doing so, we end up documenting how the build system works.  Having a good build system is important during product development so that you have an easy, repeatable process for building and deploying images.  One of these tasks is setting up a SD card and installing images to the SD card that an OMAP system can boot from.  This screencast goes over the script and makefile targets that are used to automate this process.

In summary, the steps to set up a SD card and install an image using the build template are:

  1. cd <build template directory>
  2. determine the SD card device name (/dev/sdX)
  3. unmount any file systems mounted on the SD card
  4. sudo ./scripts/ /dev/sdX  (make sure you have the right device!!!)
  5. make omap-install-boot
  6. make omap-install-<image name>-rootfs

Previous articles in this series:


Creating a Custom OpenEmbedded Image

In this article screencast, we’ll demonstrate how to create a custom Linux OS image using the OpenEmbedded build system.  This demonstration builds on the earlier article about using the BEC OE build template.  The OpenEmbedded build system is similar to Linux distributions in that you can select from a wide array of components to install.  One of the big differences is you can select these components when building the OS image, instead of after you have installed the “standard” image.  This screencast demonstrates how to set up a custom image (can be viewed with Firefox).

A related article also covers this procedure.

In summary, the steps include:

  1. Create an image recipe (typically in your meta data overlay).  An example is located here.  An existing image can be referenced for simplicity.
  2. Figure out what packages need to be added.  This can be done by browsing the recipe tree to see what is available.
  3. Bitbake the recipe.
  4. Look at what packages were generated.  In this example they are found in the build/angstrom-2008.1/tmp/deploy/glibc/ipk/armv7a directory.
  5. Add the relevant package names to your image recipe.

As the OpenEmbedded project includes over 6000 recipes, it gives you a big head start in including standard components in your Embedded Linux build.  Leveraging these existing components is why we use Linux, and having a way to easily build and deploy these components to your target hardware is what OpenEmbedded is all about.