If you contribute patches to the Drupal issue queues, you often spend a lot of time and hard work getting that patch through the review process. Even though we do it for the good of the community, once it is all said and done, it's nice to get a little acknowledgement. While there is a page for module maintainers on how to properly attribute contributions to users, not all maintainers know about that, and it can often mean they have to spend a little extra time figuring out what your Drupal.org git email address is.
The slowest, most tedious way of finding a bad git commit is something we've all done before. You checkout some old commit, make sure the broken code isn't there, then checkout a slightly newer commit, check again, and repeat over and over until you find the flawed commit.
git bisect is a much better way. It's like a little wizard that walks you through recent commits, asks you if they are good or bad, and narrows down the broken commit. In this blog post, I encourage you to create a fresh git repository and walk through each step. Hopefully, you'll gain an intrinsic understanding of
git bisect by the end of the exercise.
Git bisect is a powerful automated tool for searching deep into a project's history. Instead of searching for relevant commit messages
(git log) or patches
(git log -S), bisect actually allows you to run a functional test on each revision until the first bad commit is identified. (Okay, it doesn't test every revision, it performs a binary search, which results in at most log2(N) tests. This allows a relatively large history to be searched quickly.)
The test can be done interactively, with the human performing each check, or mechanically if you can supply a testing script. Randy Fay has done a nice screencast on the interactive method; this post will instead focus on mechanizing the process.
For an example, let's look at a core Drupal bug that impacts this very site: #812990: Search page title changes to Home. For the moment, we'll pretend the cause of this bug isn't already known, and hunt it with git-bisect.
Now that the Drupal community's migration to Git is in full swing, it's a great time to switch your own projects as well. Curious? Perhaps you saw the Git panel in San Francisco, or maybe you've listened to Sam Boyer campaigning passionately at your local DrupalCamp. Is there a rebel in your office who keeps going on about how much better life can be with git-svn? (How ironic that Subversion is now the establishment.)
If you're just getting started, here are some tips I've collected over the last year. Or if you're already a Git ninja, here's how you can help.
When Webchick announced that Drupal was moving to Git at Drupalcon 2010, our office erupted in pleasure at the news. Lots of great Drupalists are already using Git and there's even an unofficial Github branch of Drupal for your branching and stashing pleasure Github mirror. However, Metal Toad Media has been an SVN shop for a long time we still have a lot of processes that use SVN, so we elected unanimously to do a gradual rollout: new sites get a private repo on Github, old sites just use git-svn.
In my experiences in the past working with external contractors is often a pain, especially the final merge where you try to incorporate all their code. I've always been a huge proponent of Subversion for SCM but today I saw an example where Git knocked the socks off of Subversion.