bisect

Today I did my first bisect! After I did minor changes based on Dscho's comments, I noticed that now only 16 tests are passing, compared to yesterday's 18.

Relevant part of my history:

  731  git bisect start
  732  git log
  733  git bisect good cc50c8dce53c90e73e59d886ac7d1e4060a55641
  734  git bisect bad HEAD
  735  make
  736  ./test-builtin-merge.sh
  737  git bisect good
  738  make
  739  ./test-builtin-merge.sh
  740  git bisect good
  741  make
  742  ./test-builtin-merge.sh
  743  git bisect good

It turns out the bad commit was c673564678bda4a78da0b8686e64f3431ef8d144.

Somehow t3402-rebase-merge and t6027-merge-binary passes after reverting that commit.

And yes, a bit later I found the reason. (Fixed in e227f8a939d003555f3dfa7f73757b6b7ec8835c.)

Oh, I just rebased it already, so the commits are not in the public repo. But it was useful to learn now to use git bisect, I never needed it so far.

Debugging pointers

This might be something trivial but it took some time for me to figure out so I write it down here: If you want to print out a pointer address, then one easy way is:

printf("%#x\n", (unsigned)ptr);

Not too much info, but you can see if the pointer is NULL, see if two pointers refer to the same memory address, etc. Just in case valgrind would not be helpful in some special case.

get_merge_bases()'s cleanup parameter

I spent about an hour to debug this, and here is the result: you must call get_merge_bases() with the cleanup parameter enabled if you want to call it multiple times and you want to get results the second time as well. In other words, typically you should not copy&paste code from builtin-merge-base, where it's called only once ;-)