Lee Kelleher

uComponents: Moved to GitHub

Posted on . Estimated read time: 3 minutes (368 words)

Hey uComponents fans, a little status update on our version control repository move from CodePlex over to GitHub. We’d been talking about moving over to GitHub for a long time, (even before Umbraco core moved over), but the timing was never right – either we were in the middle of a major release or our day-job workloads were in high demand.  Luckily since our own v6.0.0 release, we have found the time to make the move!

The new repository is currently hosted on my personal account – https://github.com/leekelleher/uComponents – but once this has been stabilised, I will relocated it the main uComponents organisation account.

Update: The repository has now been moved to the organisation account: https://github.com/uComponents/uComponents

For those who are interested in how I migrated from our Mercurial (Hg) repository on CodePlex over to Git; we used the Hg-Git mercurial plugin to handle the main bulk of the conversion. The initial set-up had some tricky parts, mostly around installing a specific version of Python (v2.6.6) and the Dulwich library (v0.8.0+). But once configured, it all works very well.

The biggest issue I had was trying to map the commit authors with their corresponding GitHub accounts. There are various blog posts on how to generate an “AUTHORS.TXT” file that will map users/emails, but I ended up using the following Hg command to get a list of the authors from all the commits/changesets.

hg log --template "{author} = {author} rn" > AUTHORS.TXT

The output from this gave me a huge list of usernames/email addresses.  I used a feature in Notepad++’s TextFX Tools to sort and de-duplicate the lines.  From there I found the corresponding GitHub email addresses (this wasn’t pretty either – you’re on your own here).  Then I wired up hg-git’s git.author option to use the AUTHORS.TXT for the mapping.

The rest of the move to GitHub has gone successfully.  We still need to agree on a better branching structure/workflow, as the one we’ve been using for the past few years has worked well, we feel that it is off-putting to newcomers.  We are currently looking at using git-flow, but are still open to any other suggestions.