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.
Currently showing posts tagged: hacking
I recently blogged about some tools I wrote which harness the
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!
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
In the Free and Open Source software worlds, it seems that a lot of people with good intentions don’t understand how to contribute efficiently and effectively to upstream software projects. I say this based on personal experience: I sometimes receive patches to projects I maintain, where despite good intentions and a perfectly valid goal (e.g. a bug-fix or feature implementation), the patches are fundamentally flawed in a variety of ways. So unfortunately I cannot accept them without negatively impacting the quality or maintainability of the project. And I don’t even maintain any wildly popular projects.
It is possible to spend a lot of money on training to learn how to avoid these mistakes, and also many well-organized projects already provide good documentation on how to contribute, such as the Linux kernel and git. However, these documents typically mix up generic advice with project-specific advice. In this post I would like to present a list of generic advice on how to write patches which have the maximum chance of being accepted quickly and with gratitude rather than resentment!
Like many people, for a long time I have been drowning in email. I am perhaps bit unusual in that whilst my personal google inboxes are permanently overflowing, my work inboxes are generally very close to empty. This is because as a (bad) practitioner of GTD and sometime reader of Inbox Zero and similar sites, I do actually know how to get grips with email, and through professional pride apply the techniques fairly religiously when I’m working. In contrast, when it comes to dealing with personal mail, I’ll always favour procrastinating on some other interesting project instead. God forbid I should ever get my personal life in gear!
Well, this bad habit has been stressing me out for a LONG time now. I’m a long-term fan of Gretchen Rubin’s Happiness Project, and the other day stumbled across one of her older posts entitled Measure what you want to manage. I’d been wanting to graph the size of my inboxes over time, to get some grip on how bad my backlog actually is, and her post gave me the nudge to actually sort it out.
As usual, Ruby makes it almost ridiculously easy. There’s a beautiful written gem called gmail which uses IMAP to talk to your gmail account. So then it’s just a matter of writing a little program to append a line of gmail folder sizes to a CSV file every time it gets run:
#!/usr/bin/env ruby require 'pathname' require 'rubygems' # sudo gem install gmail # Note: this is an improved version of Daniel Parker's ruby-gmail # http://rubydoc.info/gems/gmail/0.3.4/frames require 'gmail' # sudo gem install fastercsv require 'faster_csv' USERNAME = 'email@example.com' PASSWORD = 'your.password.goes.here' CSV_FILE = Pathname(ENV['HOME']).join( "choose", "a", "path", "to", "gmail-counts.csv" ) labels = FasterCSV.open(CSV_FILE, 'r').shift[2..-1] FasterCSV.open(CSV_FILE, 'a') do |csv| Gmail.connect(USERNAME, PASSWORD) do |gmail| now = Time.now counts = [ now.to_i.to_s, now.strftime("%Y/%m/%d.%H:%M:%S") ] labels.each do |label| unread = label.gsub!(/ unread$/, '') folder = gmail.mailbox(label) count = unread ? folder.count(:unread) : folder.count puts "%s: %d (%d unread, %d read)" % \ [ label, count, folder.count(:unread), folder.count(:read) ] counts << count end csv << counts end end
gmail-counts.csv in the folder referenced in the script, whose header line contains a list of the labels you want counted (append
unread if you want the unread count rather than the total, and prefix “special” gmail folders with
[Google Mail]/. Here’s an example of the header followed by a single line of folder counts:
epoch,datetime,INBOX,INBOX unread,[Google Mail]/Drafts,music 1290873125,11/27/2010.15:52:05,555,20,12,1596
0 6,12,18 * * * quietrun /path/to/script/count-gmail
UPDATE 5 months later! (15th May 2011): I finally made it!