object xxx corrupted on Git server...

下午完成今天預定的SIT測項回到專案室後不久就聽到有人在召喚我 -- "James, 連不上Git啦"

心想該不會是server重開之後IP又跑走了吧, 接著putty借由顯示出login提示字元馬上打槍了, 我的第一個猜測, 嘴巴不禁嘀咕著 -- "那我們就來fetch all看看吧", 話才剛說完就立刻看到下面的錯誤訊息:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

"C:\Program Files (x86)\Git\bin\git.exe" fetch --progress "--all"
Fetching origin
fatal: object 43670bde54a8e639e3ad06e0ca9b95f3e8d790e8 is corrupted
fatal: Could not read from remote repository.


Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch origin
Done

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

反正出來跑遲早要還, 怎麼還? 通常問Google就好了

沒想這個錯誤居然是如此的generic, 可能造成的原因一籮筐, 找了半天看到一堆git指令

git fsck --full

git cat-file xxx

git repack

git ...

等做法, 但是沒一個管用的, 不過倒是對一個關鍵字印象深刻 -- "empty file"

好吧, 那就試試看把這些empty file先備份再移除看看會發生什麼事情, 但是找了半天卻找不到傳說中名稱為"43670bde54a8e639e3ad06e0ca9b95f3e8d790e8"的檔案, 說時遲那時快, 看到objects目錄下有一堆二位數hex編碼的目錄, 想說好吧那就來找找"./43/670bde54a8e639e3ad06e0ca9b95f3e8d790e8", 果然一猜就中(樂透運都這樣被用掉了吧), 仔細一看檔案大小果然是0 byte, 移除之後很開心地執行git fsck想說這樣就結束了...

事情果然沒有"拱廊"所想的那麼"甘丹", 又看到下一個object xxx is corrupted!

就這麼輪迴幾次後終於受不了, 最後大開殺戒以find . -size 0K -exec rm -f {} \;做了結.

把empty file清乾淨之後馬上又做一次git fetch --all, 立即看到不同的錯誤(表示有進展了, 值得開心 ~~), 這次的錯誤是reference的hash不存在, 好在這個提示就夠清楚明白, 把refs目錄下面meta data file裡的hash換成第二新(僅次於43670bde54a8e639e3ad06e0ca9b95f3e8d790e8)的hash後再執行git fetch --all果然可以用.

接著找出最後commit + push的人並把該更新的檔案重新commit + push一次, 終於替拯救Git server行動劃下完美句點.