There are many good reasons to maintain a proper git history, with deliberately crafted and focused commits, a state that builds, and good messages that provide context, motivation, and reasoning for the change. A neat side effect of a well kept log is that it boosts the usefulness of git bisect. Briefly, git bisect binary searches the history to find the commit which introduced the bug, and it’s an indispensable tool.

One of the aspects of Guix that really sets it apart from other package managers is how there is not much difference in power between the user and the repository. Sure, you can build your own .debs just fine and manage them with dpkg, but it takes a lot more infrastructure to have your own small packages play well with apt (and other users). For sharing packages in Guix, most of the time it is sufficient to share a small pkg.scm or similar.

Drawing insights

We can draw interesting insights from measuring code coverage. This is a binary search that I borrowed from the internet and used in my talk on prime path coverage in GCC at TechTown 2024, very slightly revised. It returns the index of the needle (x) in a sorted array, or not-found (-1) if it could not be found.

int bs(const int A[], int N, int x) {
      int min = 0;
      int max = N - 1;
      int mid = min + ((max - min) / 2);
      while (A[mid] != x && min <= max) {
          mid = min + ((max - min) / 2);
          if (x > A[mid])
              min = mid + 1;
          else
              max = mid - 1;
      }
  
      return A[mid] == x ? mid : -1;
  }

We add tests for the cases we can think of along with the expected results. All good so far, no real problems, and the tests looks solid.