雖然說看了幾個issue，大部分都插不上話－－討論的層次太高了，偶爾有個好像比較看得懂的，trace下去之後提出解法，沒想到是個不徹底的解法，pull request就被拒絕了TAT，要參加這個超過9000顆星星的project，像我這種花盆果然還是「垃圾請再加油」
－－
雖然說是這樣，但我還是趁這個機會，研究一下如何使用git bisect 在project裡面找到洞洞。
基本上project無論用了多少test，多少還是
我們用一個比較小的project: pyquery來實驗這個功能，這是強者我同學JJL大神參與的專案
https://github.com/gawel/pyquery
我們trace 一下issue 74: Behavior of PyQuery...
因為這個issue 發生在v1.2.4，但到了v1.2.9已經消失了，那我想知道這從哪裡發生的（這種狀況比較少見，一般都是有錯要找哪裡出錯了），就用bisect 來找吧。
首先是bisect 的基本設定，我們要先啟動bisect，然後指定一個good commit 跟一個bad commit，而bad commit 在歷史上要比good commit 來得晚，bisect 會從bad commit 一路回溯到good commit 為止。通常可以透過checkout tag的方式作大範圍的搜尋，以免bisect檢查太多commit，在這個例子中，我們發現v1.2.8->v1.2.9的過程中這個bug 被修掉了。
因此我們設定：
$ git bisect start
$ git bisect bad 1.2.9
$ git bisect good 1.2.8
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[bc1b16509cec70de7a32354026443fca777f4d7d] created a .gitignore file(which is almost a copy of .hgignore with some minor changes and comments)
$ git bisect bad 1.2.9
$ git bisect good 1.2.8
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[bc1b16509cec70de7a32354026443fca777f4d7d] created a .gitignore file(which is almost a copy of .hgignore with some minor changes and comments)
這時候我們已經進入bisect 狀態，用git branch的話會看到現在是(no branch)狀態。
要說明一下這裡的good, bad只是bisect上的一個概念，它會從bad 開始找到good，至於裡面是不是真的 good/bad，這由開發者決定。
這時bisect會checkout 處在good/bad 中間位置的版本，我們執行事先寫好的一個測試檔test.py，它會自動測試這個issue的狀態
from pyquery import PyQuery as pq
x = pq("<div></div>")
y = pq("<div><table></table></div>")
print(x.is_("table"))
print(y.is_("table"))
x = pq("<div></div>")
y = pq("<div><table></table></div>")
print(x.is_("table"))
print(y.is_("table"))
執行發現它還是回傳False/False，因此我們輸入
$ git bisect bad
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[b81a9e8a2b0d48ec0c64d6de14293dd4a680a20b] fixed issue #9
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[b81a9e8a2b0d48ec0c64d6de14293dd4a680a20b] fixed issue #9
bisect 會以binary search的方式checkout 一個更舊的版本，然後你再測試一次。
經過五次的bad/good的測試結果，bisect回傳：
300cd0822505a4bd308acd1520ff3ef0f20f8635 is the first bad commit
commit 300cd0822505a4bd308acd1520ff3ef0f20f8635
Author: Gael Pasgrimaud <gael@gawel.org>
Date: Fri Jan 3 10:35:30 2014 +0100
fixed issue #19
:040000 040000 1d9cb3b170a8fdb2846e3c0e0fb6d2be9a9538d5 07d3a40ff73dda078d7543be2fab2f9f927b0c1f M pyquery
commit 300cd0822505a4bd308acd1520ff3ef0f20f8635
Author: Gael Pasgrimaud <gael@gawel.org>
Date: Fri Jan 3 10:35:30 2014 +0100
fixed issue #19
:040000 040000 1d9cb3b170a8fdb2846e3c0e0fb6d2be9a9538d5 07d3a40ff73dda078d7543be2fab2f9f927b0c1f M pyquery
這樣就抓到這個 fixed issue #19 的commit 就是修好這個issue 的commit 了，最後要用
$ git bisect reset
結束bisect狀態。－－
上面這個方法好像還是不夠方便，理論上bisect 支援git bisect run這個方法，可以送一個script 給它，它會自動執行，並以回傳值0表示這個commit 是good，回傳值1表示這個commit 是bad，回傳值125表示這個commit 要skip掉。
所以我改了上面這個script 為：
import sys
from pyquery import PyQuery as pq
x = pq("<div></div>")
y = pq("<div><table></table></div>")
if x.is_("table") == False and y.is_("table") == False:
sys.exit(1)
else:
sys.exit(0)
可是不知道為啥，bisect run ./test.py的結果，每個commit 都會是bad的輸出…這真的是太奇怪了，我猜有可能會是git bisect的問題也說不定，有空再來詳加研究。from pyquery import PyQuery as pq
x = pq("<div></div>")
y = pq("<div><table></table></div>")
if x.is_("table") == False and y.is_("table") == False:
sys.exit(1)
else:
sys.exit(0)
－－
8/28增補：
後來經過阿蹦大神的指出，問題可能是出在*.pyc上面，因為python要是看到現在的pyc跟現在的時間相同，就不會更新pyc而是直接跑pyc。
git bisect run會極速的checkout 舊分枝，跑python script，看結果跑下一步；而pyc的檢定大概是用秒在算的，就變成python並沒有更新pyc檔，反而是用pyc跑出同樣的結果，bisect 自然出錯了。
解決方法有兩個，第一個是寫一個shell script test.sh，先刪掉所有pyc檔之後，再執行python script:
find . -name “*.pyc” -exec rm {} \;
./test.py
然後用git bisect run ./test.sh./test.py
第二個是讓python script 跑慢一點，讓python能察覺到python 的版本變化：
import time
time.sleep(1)
第三個應該才是根本的解法：time.sleep(1)
在python 的shebang上面加上 -B的參數就好了
執行結果就跟手動的一樣了，去你的pyc。結論：
bisect很好用？不是，我認為從這個案例中最重要的概念，其實是自動測試的重要性，如果程式能保持一個自動測試的script，在除錯上可以透過script 自動找到錯誤點，不需要人工手動介入，試想若每個commit都需要手動10步驟的測試，兩個版本間有10個commit ，測試步驟立刻變成100步，但用script只要一個指令就能知道是好是壞，搭配bisect才能事半功倍。參考資料：
Git-bisect doc: http://git-scm.com/docs/git-bisect
