5 ms·
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://web
by warpech 9y ago
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 http://webchick.net/node/99
- hacker_9 9y agoUsed 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.
- devrandomguy 9y agoGit bisect is awesome. Before I discovered it, I was manually bisecting the codebase, and stubbing out the missing half.
- adrianratnapala 9y agoNot 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.
- MaulingMonkey 9y agoThey'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.
- pmarreck 9y agohow 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.
- sethrin 9y agoI 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.
- pmarreck 9y agoThat'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.
- sethrin 9y agoI 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?
- azhenley 9y agoThis 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.
- pishpash 9y agoYou may be implementing an intuitive weighted bisect :)
- maccard 9y agoHeh, I do a binary search. Find last known good build, go half way between, etc
- ChronosKey 9y agoThat's what git bisect does
- maccard 9y agoAnd not everyone uses git, unfortunately.
- mcintyre1994 9y agoThis is what git-bisect does :)
- muxxa 9y agoI 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
- Anderkent 9y agoThe 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.
- epmatsw 9y agoI 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.