Finding first broken build with git-bisect

With git it's so easy to find which commit broke the build. Suppose you know that commit with tag release-1.0 was good, i.e. all tests passed. The latest commit, however, is failing.


So the build was broken somewhere in between release-1.0 and master HEAD. To find the exact one you just need to run two git commands. First

$ git bisect start HEAD release-1.0

Here you specify which commit you know is broken, and which one you remember was successful. After running this command you can see that git marked two commits with good and bad labels, and put the search starting point at the revision in the middle.


The second command is git bisect run cmd, where cmd is the script used as a criterion of successful build. If you use Maven then your command would be:

$ git bisect run mvn clean test

After you hit Enter button in the terminal, git starts running your criterion script using binary search algorithm. It might take time to finish this task, which depends on the number of revisions and the execution time of the script. Eventually it stops and shows you which commit caused the build failure.

7933e4658ea852754120fbc8fec34b2b85932e48 is first bad commit
commit 7933e4658ea852754120fbc8fec34b2b85932e48
Author: Andrey Paramonov 
Date:   Wed Nov 25 21:07:30 2009 -0500

    Changed method implementation

:040000 040000 c0f3f9ef13d7daa4671205b9518c168a9ac10fe3 5a1cf3d6fb28d6f815c172319630b5d55ce4dc10 M     src
bisect run success

If you look at the visual tool, you will spot the first bad commit by the label bisect/bad.


Resources

• git-bisect manual page

State Machines in Erlang

There is some sort of confusion in the object-oriented community about functional languages. How is it possible to implement stateful application if the language has no concept of state? It turns out that it's actually quite possible, although the solution is completely deferent from what we see in the OO realm. In Erlang, for example, state can be implemented by using process messaging and tail recursion. This approach is so elegant that after you've learned it, the OO way of doing this looks unnatural. The code below is the Erlang implementation of Uncle Bob's FSM example. Look at it. Isn't that code clean and expressive? It looks almost like DSL but it's actually regular Erlang syntax.

-module(turnstile).
-export([start/0]).
-export([coin/0, pass/0]).
-export([init/0]).

start() -> register(turnstile, spawn(?MODULE, init, [])).

% Initial state

init() -> locked().

% Events

coin() -> turnstile ! coin.
pass() -> turnstile ! pass.

% States and transitions

locked() ->
    receive
        pass ->
            alarm(),
            locked();
        coin ->
            unlock(),
            unlocked()
    end.

unlocked() ->
    receive
        pass ->
            lock(),
            locked();
        coin ->
            thankyou(),
            unlocked()
    end.

% Actions

alarm() -> io:format("You shall not pass!~n").
unlock() -> io:format("Unlocking...~n").
lock() -> io:format("Locking...~n").
thankyou() -> io:format("Thank you for donation~n").

The idea behind this code is simple. Every state is implemented as a function that does two things: it listens for messages sent by other processes; when message is received the appropriate action is taken and one of the state-functions called recursively. Simple, right? And thread-safe!