Hacker News Reader

Comment by warpech | Hacker News Reader

Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps.

Some random blog post about it: http://webchick.net/node/99

The algorithm described in the article, if I'm reading it correctly, is more powerful than git bisect, because it can identify the exact change within a commit that causes the bug. You could for example decide to make each file modification in a commit a different 'Change', and so the algorithm would identify not only which commit breaks something, but which file changes are relevant.

This would be difficult to determine - as running tests without some changes in non-deterministic way could affect testing or the program's ability to run properly.

The article covers that.

I think what blew my mind most was `git bisect run`. Write a test case, go get coffee, have git spit out the offending commit automatically. So cool.

Used this the other day! Had to track down a visual bug that was introduced in the last 20 commits, but with binary search I could narrow down on the problem a commit at a time and so only had to look at 4 in total.

how am I not surprised that this solved a regression that occurred at some point in the past on a Drupal project

I worked on a Drupal project... Once.

I believe Joomla is worse in every conceivable way. And then of course there is WordPress, which I sincerely hope is the last major procedurally-written codebase. PHP has come a long way as a language (it can almost be confused for something sensible these days) but lots of issues with large libraries.

That's why I left the Ruby ecosystem and went to Elixir. I noticed that my coding style was getting more and more functional (just naturally... but I was also probably influenced by Rich Hickey's "Are We There Yet?" talk, and by Gary Bernhardt's "Boundaries" talk) and soon realized that functional nirvana was essentially unachievable in Ruby as long as I depended on a vast library of gems all of which were procedural/OO.

Leaped and haven't looked back yet. Great stuff.

I started in PHP, migrated to Ruby, and now I think I am beginning to be annoyed at Ruby's occasional lack of expressivity. I am probably on a similar course towards FP nirvana. Do you know any place on the left coast that's playing with Elixir or Haskell?

More places than on the right coast! :O

Fair enough. I'll let you know when I find it :)

This is awesome. Didn't know about it, thanks!

My approach has been to step exponentially. I go back 1 commit, 2 commits, 4 commits... etc. I'll be using bisect from now on though.

You may be implementing an intuitive weighted bisect :)

Heh, I do a binary search. Find last known good build, go half way between, etc

That's what git bisect does

And not everyone uses git, unfortunately.

This is what git-bisect does :)

I wish git bisect could handle the 'find last good build' step by jumping back exponentially through history, then switching to binary search once the last good build is found

Git bisect is awesome. Before I discovered it, I was manually bisecting the codebase, and stubbing out the missing half.

Not to take away from git bisect (or hg bisect, which is no more broken than the rest of mercurial) -- I don't think it is an alternative to the thing you used to do.

git bisect is "temporal bisection", i.e. you delete half of a time interval. The manual bisect is kinda-sorta "spatial" in the sense that you delete half a region of code. the two things work by similar principles, and their problem domains overlap -- but they are not the same.

They're complimentary techniques. One might git bisect down to the commit level, then manually bisect the sub-changes in the commit if it's a large one.

I've done the manual equivalent in perforce as well.

Reply on news.ycombinator.com