Facebook goes some way towards making it easy for you to invite groups of friends to an event, but it still requires a mouse click for each person you want to invite. If you have a friend list containing more than a handful of people, this rapidly gets tedious. Don’t worry though! Here’s a way to select the whole list in one go.
I recently blogged about some tools I wrote which harness the
notes feature of git to help with the process of porting commits from one branch to another. Since then I’ve discovered a couple more consumers of this functionality which are pretty interesting:
palaver, and Gerrit.
Have you ever needed to port a selection of commits from one git branch to another, but without doing a full merge? This is a common challenge, e.g.
- forward-porting / upstreaming bugfixes from a stable release branch to a development branch, or
- back-porting features from a development branch to a stable release branch.
Of course, git already goes quite some way to making this possible:
git cherry-pickcan port individual commits, or even a range of commits (since git 1.7.2) from anywhere, into the current branch.
git cherrycan compare a branch with its upstream branch and find which commits have been upstreamed and which haven’t. This command is particularly clever because, thanks to
git patch-id, it can correctly spot when a commit has been upstreamed, even when the upstreaming process resulted in changes to the commit message, line numbers, or whitespace.
git rebase --ontocan transplant a contiguous series of commits onto another branch.
It’s not always that easy …
However, on the occasions when you need to sift through a larger number of commits on one branch, and port them to another branch, complications can arise:
- If cherry-picking a commit results in changes to its patch context,
git patch-idwill return a different SHA-1, and subsequent invocations of
git cherrywill incorrectly tell you that you haven’t yet ported that commit.
- If you mess something up in the middle of a
git rebase, recovery can be awkward, and
git rebase --abortwill land you back at square one, undoing a lot of your hard work.
- If the porting process is big enough, it could take days or even weeks, so you need some way of reliably tracking which commits have already been ported and which still need porting. In this case you may well want to adopt a divide-and-conquer approach by sharing out the porting workload between team-mates.
- The more the two branches have diverged, the more likely it is that conflicts will be encountered during cherry-picking.
- There may be commits within the range you are looking at which after reviewing, you decide should be excluded from the port, or at least porting them needs to be postponed to a later point.
It could be argued that all of these problems can be avoided with the right branch and release management workflows, and I don’t want to debate that in this post. However, this is the real world, and sometimes it just happens that you have to deal with a porting task which is less than trivial. Well, that happened to me and my team not so long ago, so I’m here to tell you that I have written and published some tools to solve these problems. If that’s of interest, then read on!
I’ve been a bit of a hermit the last few weeks, burning the candle both ends and spending the majority of my spare time building a new toy … well actually it started out as a toy, but now I think it’s good enough for musicians to use as a serious tool for improving their improvisation / compositional skills, and harmonic understanding.
So I’m very pleased (and relieved) to be able to announce … <drum roll> … the Scale Matcher! It should work equally well on your computer, phone, and tablet. Please try it out and let me know what you think! You can also click the About and FAQ buttons to find out more.
Thanks to Barak Schmool for providing the original inspiration to do this, and for the time he spent testing it out and suggesting improvements.
Julien Danjou recently posted a thought-provoking rant about GitHub’s pull request workflow implementation. His main point is essentially that Gerrit provides a more sophisticated review system. Of course I’m not going to disagree with that
I am generally a big fan of Julien’s work and I’m very excited for the future of OpenStack Ceilometer of which he is the current PTL. However, in this case I think his views are understandably biased towards review workflows on very large projects like OpenStack, and I found the length of the rant slightly disproportionate to the actual substance of the points made within it. Somewhat ironically, AFAICS his blog’s own review process could use some improvement due to comments currently being disabled So here are my thoughts.
Disclaimer: currently I use GitHub for reviews more regularly than Gerrit, so my views are likely to be biased at least as much as Julien’s, but in the opposite direction