Chris M.

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...

A user emailed me today asking if I could push out some changes to a network packet analysis and creation library that I created and maintain, Packet.Net . These changes were included in the last release packages I pushed our a few months ago but apparently weren't in the git repository on SourceForge. This didn't make a lot of sense because I use some scripts that build binary and source release zip files by doing a git export of a specified tag from the remote repository on SourceForge. Plus I'm usually pretty careful to push everything out in case something happens to my laptop. Went to the SourceForge code browser web page where you can browse the repository from a web browser and sure enough there were tags and commits were missing, when compared to my local development repository/directory. I ran git status from my development directory and it showed up to date. Ran a push but it said the same. Even tried a force push but git didn't take any action. I suspecte...

The version control system your project uses can have a big impact on how easy it is for outside contributors to help out. Svn (and cvs) make it difficult to contribute Most projects restrict new or minor contributors to read only permission on their code repositories. This is common both for security and for organizational purposes, project maintainers often like to review changes before they go into mainline code. Read only access has its downside for contributors. If someone like myself wanted to contribute to a project that used svn the flow wold look something like: - svn checkout - Edit files in my editor - Test - svn diff > changes.patch - Email/post changes to maintainer - Wait until the changes are approved or rejected and checked in to svn - Repeat starting at 'Edit files in my editor' The bottleneck here is waiting for changes to be checked into svn. What if there were several changes in series? How would I be able to continue working on the next chang...