New open source project on work time – git-history-data

Announcing a little open source project that I have built at work and been allowed to publish Freely.

git-history-data analyses a Git source code repository and dumps out data in a form that is easy to analyse.

I wrote an article demonstrating how to use it to find out some interesting information about the codebase of Git itself and got it published on IBM DeveloperWorks Open: Learning about the Git codebase using git-history-data.

Difficult merges in Git – don’t panic!

A video in which I try to explain what merging and rebasing really are, to help you understand what is going on when Git presents you with scary-looking conflict messages. I also explain why you shouldn’t panic because it’s hard to lose your work, and how to get you work back if you really mess up:

Slides here: Difficult Merges in Git.

A commit represents the state of the world (and the history leading up to that state). A commit is not a diff.

Merging means making a new commit with two (or more) “parents” (previous commits) that represents the result of merging the changes from two different threads of development that happened separately. None of the already-committed commits are modified – you just get a new commit on top. History is more complicated, but true.

Rebasing means modifying the history of one thread of development so it looks like it happened after the other one. This involves modifying all the commits in that thread. There is no extra merge commit, so you lose the history of the merge that happened. History is simple, but it’s a lie, and if you messed up the rebasing process, you can’t get back to where you were (once your old commits have been garbage-collected).

Options for code reviews with Git

We’re thinking about switching to Git for my work, and I want to be confident we can still support good code reviews if we make the switch.

I am a big fan of in-person reviews, and for that, git difftool is enough but sometimes you need to do it asynchronously, and then you need a tool or a process or something.

Here are the options as I see them so far (please comment if you know others I should consider):

  1. Emailing patches. Git has git format-patch and git bundle that allow creating a file containing changes that can be sent by email or message. These can be reviewed as patches or applied to the working tree and reviewed in context.
  2. Feature branch and pull request. Devs to push their changes to a branch in a shared repo and send an email or message asking a colleague to pull the branch. The reviewer looks at the changes in the repo or pulls them, then either sends back comments, or merges the branch into their own and delivers to the master branch.
  3. Tools. There are several extra tools that sit in front of Git and deliver changes when they are reviewed. These include: Gerrit, Critic, Review Board.

References: