GIT is a wonderful tool. It enables some really powerful, flexible working models. There is one model that is commonly used when developing a major feature (or large refactor):

• Create a long series of patches in the order that it makes sense to develop them.

• Rebase, reorder, and merge patches into the order that it makes sense to review them.

• Post patches for review in small, easy to digest groups.

There is a danger in this process. While reordering patches it is very easy to create a tree that won't build at intermediate commits. Since the entire group of patches gets pushed at once, this may not seem like a problem. However, having intermediate commits not build makes it impossible to bisect when failures are found later.

Having every commit along a long patch series build is an absolute requirement.

However, it's kind of a pain in the ass to manually build the tree at every step. The emphasis in the previous sentence is manually. In some sense the ideal tool is something like a scripted bisect. This doesn't work, of course, because both ends of the commit sequence, in bisect terminology, are good.

To get around this in Mesa, I wrote a script that builds origin/master and every commit in some range of SHA1s. If any build fails, the script halts. At the end, it logs the change in the compiler warnings from origin/master to each commit (as I write this, it occurs to me that the warning diffs should be between sequential commits). This is useful to prevent new warnings from creeping in.

My script is available. This particular script is very specific to Mesa, but it should be easy to adapt to other projects. The script is run as:

check_all_commits.sh /path/to/source /path/to/build firstSHA..lastSHA