Currently showing posts tagged: hacking

more uses for git notes, and hidden treasures in Gerrit

By , October 2, 2013 2:05 pm

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'»

Share

Easier upstreaming / back-porting of patch series with git

By , September 19, 2013 9:22 pm

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-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.

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-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.
  • If you mess something up in the middle of a git rebase, recovery can be awkward, and git rebase --abort will 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!

Continue reading 'Easier upstreaming / back-porting of patch series with git'»

Share

in partial defense of GitHub’s review system

By , May 12, 2013 12:47 pm

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'»

Share

7 principles for contributing patches to software projects

By , November 10, 2012 3:28 pm

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!

Continue reading '7 principles for contributing patches to software projects'»

Share

measuring email inbox sizes

By , November 28, 2010 6:35 pm

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 = 'your.account.name.goes.here@gmail.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

Then create 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

Then make sure the program is automatically run on a regular basis somehow. On Linux this is as simple as adding a new line into your crontab. My quietrun utility comes in handy for this:

0 6,12,18 * * * quietrun /path/to/script/count-gmail

Then you can use Google Docs or your favourite spreadsheet / charting application to plot some nice graphs. I used this script which is written in the Ploticus graphing language; here is the result:

sample graph of gmail inbox size over time

Easy!

UPDATE 5 months later! (15th May 2011): I finally made it!

Share

Panorama Theme by Themocracy