解剖 .git 資料夾 part. 2 - Blob Object

在前面的 解剖 .git 資料夾 part. 1 - Git Init 我們已經初步瞭解了 .git 資料夾初始化後的結構，但是其中 objects 這個資料夾是空的，就讓我們來看看 執行 git add 後是如何將檔案存放在 objects 資料夾下

Blob object 介紹

由於目前我們還沒有任何的檔案，讓我們新增一個 README.md

echo "This is readme." > README.md

再來執行 git add README.md 來將他加到 git 的索引裡，完成後 git status 的結果應該會像下面這樣：

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

這時候我們可以來看一下 .git/objects 下的檔案長什麼樣子

objects/
  ├─ pack/
  ├─ info/
  └─ 52/
     └─ cb6cdb81a64344370c918a301eb153035f915a

blob object 內容

這時候多了一個名字叫 52 的資料夾，底下有一個檔案叫 cb6cdb81a64344370c918a301eb153035f915a，如果你把他打開會發現內容是看不懂的

$ xxd .git/objects/52/cb6cdb81a64344370c918a301eb153035f915a
00000000: 7801 4bca c94f 5230 3463 08c9 c82c 5600  x.K..OR04c...,V.
00000010: a2a2 d4c4 94dc 543d 2e00 5ee3 0781       ......T=..^...

原因是所有在 object file 下的檔案都會經過 zlib 壓縮後存放，解壓縮後我們可以看到 object file 的內容是由以下的結構所組成

  • blob + 空格 + 檔案大小 + zero btye + 原始檔案的內容

比較特別的是檔案大小會用十進位來儲存，會直接寫 1 和 6 的 ASCII code 而不是十六進位的 00 10 (我們檔案在最後面有換行符號，所以 size 是 16)

$ openssl zlib -d -in .git/objects/52/cb6cdb81a64344370c918a301eb153035f915a | xxd
00000000: 626c 6f62 2031 3600 5468 6973 2069 7320  blob 16.This is
00000010: 7265 6164 6d65 2e0a                      readme..

git 其實也有提供工具來幫忙解壓縮和印出內容

我們需要先得到完整的 object hash 兩碼資料夾 + 檔名 = 52cb6cdb81a64344370c918a301eb153035f915a

當我們有了 object hash 之後可以用

  • git cat-file -t <HASH> 來印出 object 類型 blog
  • git cat-file -p <HASH> 來印出內容 This is readme.
  • git cat-file -s <HASH> 來印出檔案大小 16

blob hash 由來

這個長長的 hash 其實是用未壓縮的檔案內容做 SHA-1 hash 之後得到的結果，我們可以用 sha1sum 指令來測試

$ openssl zlib -d -in .git/objects/52/cb6cdb81a64344370c918a301eb153035f915a | sha1sum
52cb6cdb81a64344370c918a301eb153035f915a *-

由於是依照檔案內容來計算出來的 hash 當 object 檔名，如果有內容完全一樣的檔案就可以直接共用來省空間，另外用兩碼來切分資料夾也可以避免在同一個資料夾中有過多的檔案，有助於提高尋找和管理的效率

BTW 如果想要用 SHA-256 演算法來算 object hash 也是可行的，只要在 git init 的時候用 --object-format=sha256 來指定即可

這篇就先講到這邊，我們接下來可以來看一下 .git/index 這個檔案的內容

如果覺得內容有幫助可以給個拍手~ 

​

留言

張貼留言

這個網誌中的熱門文章

unit testing 的第一步：使用 gcov/lcov 統計 c++ project 的 testing coverage

圖片
在寫 unit testing 時偶爾會不小心漏掉了一些 case 導致測試不完整，coverage report 可以幫我們做初步的檢查，確保測試程式有一定程度的品質，還可以順便抓出沒有用到的 code gcc --coverage 為了產生分析 coverage 必要的資料，我們必須在 compiler 時加上 --coverage 的參數，才能夠在程式執行時，得知每行程式碼是否有被跑到，在 link 時也要加上 --coverage 。重要的是還要將最佳化關掉，避免最佳化影響統計的結果，可以參考 CMakeLists.txt ，我使用的 gcc 版本為 7.4.0。 SET (GCC_COVERAGE_COMPILE_FLAGS "-g -O0 --coverage" ) SET (GCC_COVERAGE_LINK_FLAGS "--coverage" ) SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}" ) SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${GCC_COVERAGE_LINK_FLAGS}" ) 透過這樣的參數來 compile 後，可以發現所有 *.o 的旁邊都多出了 *.gcno 的檔案，可以想成他記錄了每一行的程式碼，之後要用來比對是否有哪一行沒有被執行到 範例 完整的 code 一樣放在 github 這次的範例包含了一個 TestClass 在 libarary 中，裡面有 private function 和會被測試到與不會被測試到的 function 各一個 void TestClass::TestedFunction( bool cond1, bool cond2) const { PrivateFunction(cond1, cond2); } void TestClass::UntestedFunction() const { PrivateFunction( false , false ); } void Tes
閱讀完整內容

在 python 中透過 ctypes 執行 C++ library 的 class

圖片
動機 目前大部份的程式都是用 C++ 來實作，不過有時候會有使用 python 比較方便的時候（例如做 API 的整合測試），這時候可能會在 python 實作一些和 C++ unit test 中一樣的邏輯，但直接重寫一次很容易在日後修改時發生行為不一致的狀況，因此讓 python 能夠直接使用 C++ 的 library 就是比較好的選擇 解法選擇 Boost.Python Python ctypes library 除非本來的 project 就有使用到 boost，否則要將 Boost.Python compile 起來是需要花一些工夫的，這邊會比較建議使用 ctypes library，但是 ctypes 只能夠支援 C 的 interface，這篇文章會教你如何將 C++ 的 class 透過 wrapper 的方法轉到 python 上，這方法是幾個月前從 stackoverflow 上看到的，我覺得比較容易讓 python 和 C++ 上對該 class 的使用體驗一致，分享給大家 Example 完整的 範例程式碼 都有放在 github 上 程式解說 每個檔案的說明如下： library.h library.cpp: 實作 class main.cpp: 使用 library.cpp 提供的 class 做 demo library-python.cpp: 提供介面給 ctypes library.py: 透過 ctype 提供 python 版本的 class ctypes-demo.py: 如同 main.cpp，使用 library.py 提供的 class 由於 cytpes 只支援 C 的介面，因此我們需要將 class 的每個操作都寫成 function 的形式(包括 constructor、destructor)，並透過指標來 access member，這邊列出一部份的 code TestClass* TestClass_new() { return new TestClass(); } int TestClass_member(TestClass* ptr) { return ptr->member(); } 接著在 python 端，就可以透過
閱讀完整內容

在 blogger 寫 markdown 最接近完美的辦法

圖片
動機 在好幾年前寫過幾篇技術 blog 文章，雖然當時只是希望分享給同學看，最後竟然也有一些人透過 google search 找到，也有在留言區討論問題。但畢業後就沒有再動過了，最近又想把寫 blog 的習慣重新撿回來。 內容的話目前希望有自己 side project 相關的隨意筆記，或是讀書後的詳細心得 (常常覺得書中講得不夠詳細，或是範例不夠完整) 選擇 blog 平台 最近 markdown 語法開始進入公司內部各種文件的撰寫，自然我也想使用 markdown 做為寫 blog 的語言。我喜歡 markdown 可以將內容與 style 完全切開的設計，就好比使用純 html + css 來製作網頁一樣，markdown 主攻內容，至於最後的呈現部份可以另外找到各種外掛幫你 render 成想要的樣子，這邊就列出了我找平台的條件： 如果能自己架是最好，線上服務的話要有信心不會倒 能夠原生或使用 plugin 來支援 markdown 要有留言系統 可以自己調整 style 技術 blog 永遠少不了的 code syntax highlight 接著上網陸陸續續找了幾種解法： Wordpress 這個方法一開始在我心中就被排除了，原因只是個人覺得 wordpress 功能太過強大，幾年前有架起來一個 wordpress 站，常常會為了一個 plugin 搞半天，處理 plugin 版本相容問題，plugin 之間相容問題，後台的設計讓功能不是非常好找，拿來作為個人網站比較合適，以純 blog 需求來看有點殺雞用牛刀的感覺 Medium 和 wordpress 一樣原生不支援 markdown，而且無法自己換 style，所以不採用 Jekyll 搭配 git 來寫 blog，聽起來很工程師很酷XD，所以有實際跑起來測一下，遇到了幾個問題最後放棄了： Jekyll 要搭配 ruby 使用，雖然我在 linux 與 windows 的電腦都有成功安裝了，但換到新的電腦就要重新安裝一次 由於是靜態網頁產生器，如果要做留言的話要另外處理，這時又會出現選留言平台的問題…(線上怕倒，自己架花時間，或是要錢) render 有點迷樣，例如有三個 page，其中一個 page 沒有寫 title 屬
閱讀完整內容