Mercurial “Not At A Branch Head” Error

Although I write and speak a lot about various kinds of source control (git and subversion are the most popular still as far as I can see), my own development projects are on BitBucket under mercurial (bitbucket also offer git hosting these days, and their tools are great). Recently I was working on an upgrade for BiteStats (note shiny new theme, with thanks to @miss_jwo) and I kept getting this error from hg tag

not at a branch head
Continue reading

Mercurial Primer

I am a source control nut, I’ve been speaking about Subversion for years, I co-lead an active open source project which uses git and GtiHub, and I’ve also dabbled with Bazaar. So far I’m feeling the limits of Subversion, loving the code-hosting features of some of the DVCS tools, and hating git and github in equal measure (don’t bother to try to talk me out of this, I’m well aware the problems are mostly on my side). I don’t know anyone else using Bazaar in the PHP community but I do know quite a few people raving about Mercurial, or Hg. This post is a quick introduction to the commands I have been using since I started trying out Hg and BitBucket for myself.

Continue reading

Speaking at PHP London, October 2010

In October I will be speaking at the PHP London user group on Thursday 7th at the Theodore Bullfrog pub in London. I’m giving a new talk called “The Source Control Landscape”, looking at the products currently available in the source control arena, how the distributed systems have changed the landscape, and how we can choose between them all today. I’m really looking forward to the event, it’s always a good crowd and I love to meet new people as well as meet up with existing friends – see you there :)

Migrating Github Contributors to an Organization

Recently, a github project that I contribute to, joind.in, moved from an ordinary github user account over to an organization. Getting contributors moved over is pretty straight forward, I have a fork of the main repo on github at http://github.com/lornajane/joind.in and that updated to show itself as being a fork of the organisation’s repo rather than the original user repo that it had been set up under.

In fact, all I had to do was update my upstream remote on my local repo – I set this up following the excellent github forking instructions when I first forked the repo. All I did then was to check my remotes:

git remote

This showed my remotes with the “upstream” pointing to the old repo. So I copied the URL of the organization repo, removed the old version and added a new upstream:

git remote rm upstream
git remote add upstream git://github.com/joindin/joind.in.git

Everything now behaves as before while handling the new central repo for the project – hopefully this helps others with projects moving from user accounts to organizations (or organisations, as I keep typing, British spellings as always!)

Working with Branches in Git

Recently I’ve been doing more git than I ever intended to, working with the Joind.in codebase, contributing and managing contributions to that. I quickly realised that I needed to make changes on branches, and since I’m new to git, it took a while to figure some of this out. I’m pretty confident now* so I thought I’d share how I work with branches in git.

Available Branches and The Current Branch

This is the easy bit:

$ git branch
* api
  master
$

The entry with the star next to it is the current branch, so here you can see that I have branches “master” and “api” and I’m currently working on the “api” branch. If you only have one branch it will usually be called “master”.

Creating and Changing Branches

My experience is with Subversion until now, and branching is really different in git (because it actually has branches rather than just copies, this is definitely a feature, but it is a different approach from how I had used them before). So you can switch your working copy around to look at different branches, which threw me a bit to begin with. To change branches, just checkout the one you want:

$ git checkout master
Switched to branch 'master'
$

If you actually wanted a new branch simply name it and ask checkout to create it if it doesn’t exist, by using the -b switch:

$ git checkout -b demo
Switched to a new branch 'demo'
$

So now my branch command shows me this:

$ git branch
  api
* demo
  master
$

Pushing Branches

This is very much an optional step. Many of my branches are private branches – meaning that I branch on the development server, finish the feature at hand, and then merge the changes into my master branch without pushing the branch to anywhere else. To share changes with others though, I sometimes like to push my changes up to github – which is my “origin” remote on my repo. So to push the demo branch we just made, I would simply do:

$git push origin demo
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:lornajane/joind.in.git
 * [new branch]      demo -> demo
$

If you use “git push” on its own, it will push all branches which exist on both the local repo and the origin – but will not push any private branches unless you specify that it should.

Resources

The http://help.github.com site, Github’s own documentation, is actually brilliant and has really helped me to get up to speed with working with my own code and contributions from others.

* The only problem I’ve had with code on github recently is that I merged totally the wrong changeset into the main project root. Which really isn’t the fault of the source control system :)