Comments (2) 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.
Continue reading 'more uses for git notes, and hidden treasures in 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.
Of course, git already goes quite some way to making this possible:
RSS for: 
git cherry-pick can port individual commits, or even a range of commits (since git 1.7.2) from anywhere, into the current branch.
git cherry can 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 --onto can transplant a contiguous series of commits onto another branch.
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:
git patch-id will return a different SHA-1, and subsequent invocations of git cherry will incorrectly tell you that you haven’t yet ported that commit.
git rebase, recovery can be awkward, and git rebase --abort will land you back at square one, undoing a lot of your hard work.
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!
Continue reading 'Easier upstreaming / back-porting of patch series with git'»
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 😉
Continue reading 'in partial defense of GitHub’s review system'»
Panorama Theme by 
Themocracy