Why open source projects should use 'git rebase' or the equivalent

May 18, 2011

One of those 'vigorous debates' in version control is whether you should make frequent use of rebasing changes in order to present a clean version history or whether you should preserve the original, real development history of changes, warts and merges and all. As it happens I am a somewhat involved bystander in this, so I have a grumpy sysadmin's answer: if you are an open source project of moderate size or larger, you should absolutely rebase patches. In fact it would be good if you went further than that.

Why is simple: git bisect and equivalents in other DVCSes. The more you have working bisection, the more outside people (like me) can send you problem reports about your new release or beta that include the magic phrase 'and this specific change is where it broke'.

(In many cases, this phrase drastically reduces how much time you have to spend debugging and fixing problems.)

When it works, bisection is marvelous. But, speaking from personal experience, when I am trying to bisect through strange code and I hit an unbuildable or untestable tree, I pretty much give up on the spot. I simply don't know enough about your project to deal with the issues of bisecting through and around a bad tree (especially given the paradox of too detailed bug reports).

When I'm bisecting, having a project history that includes every partially done modification, misstep, checkpoint, and failed approach that a developer ever made is not a feature. Even if the tree builds and is testable, the presence of partially complete modifications may mean that my bisection confidently declares that the problem changeset is halfway through the development of a modification. This is technically correct but almost certainly not useful, because what you want me to tell you is which fully developed change created the problem.

(Now that I think about it, part of the problem with bisection here is that a binary search is not quite the right model for what you want to do, at least in the general case. But that's another entry, once I've thought about this a bit more.)

So: once your project is large enough that it's helpful to have outside people bisecting things to find where problems were introduced, you want a clean history to enable this as much as possible. Thus you want to rebase, and ideally you would have a rule that all changes committed to the master tree must leave it buildable and testable.

Comments on this page:

From at 2011-05-19 11:26:44:

You can get `git bisect' to run a script[1] for each commit it decides to iterate on (which is a good idea when there are lots of steps to wade through anyhow), and one of the exit values (125) signifies that the current source code is bad and so should be skipped.

This isn't ideal, as you end up with some difficulty in deciding what commit really caused the problem, but I'd rather see lots of small commits than huge uber-commits. Rebase (and my current favourite of commit --amend) still have a place to squish together some broken commits, I agree, but you can (mostly) work around them when bisecting :)

[1] ``git bisect run <cmd>...'' from the man page

By cks at 2011-05-19 12:37:51:

The script only really helps if you can automatically test the results. For a number of cases that I'm interested in (such as Linux kernels), this is not true; testing requires manual steps.

I suppose you could make a script that ran the build, returned a 'skip' result if the build failed, and then paused to let you run manual tests and tell it what the result was. I kind of wish that git had some sort of build test hook built into bisection, so you could tell it to run a command when you moved the bisection point and automatically skip that version if the command failed.

Written on 18 May 2011.
« What we could use 10G Ethernet for in the near future
One limitation of simple bisection searches in version control systems »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed May 18 00:50:33 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.