使用 NFS 將 Git 提交記錄顯示成文件目錄
大家好！某天，我突發奇想 —— 是否能把 Git 存儲庫制作成一個 FUSE 文件系統，然后把所有的提交記錄做成文件夾呢？答案是肯定的！有 giblefs、 GitMounter 和用于 Plan 9 號的 git9。
但在 Mac 上使用 FUSE 實在很煩人 —— 你需要安裝一個內核擴展，但由于安全的原因，Mac OS 上安裝內核擴展看起來越來越難了。此外，我還有一些想法，希望能用與這些項目不同的方式來組織文件系統。
因此，我想在 Mac OS 上嘗試 FUSE 以外的掛載文件系統的方法會很有趣，因此我創建了一個名為 git-commit-folders 的項目來做這個事。它可以同時使用 FUSE 和 NFS（至少在我的電腦上），WebDav 的實現起來還有點問題。
這個項目很有實驗性（我不確定這究竟是一個有用的軟件，還是一個思考 Git 如何工作的有趣玩具），但寫起來很有趣，我自己也很喜歡在小型存儲庫中使用它，下面是我在寫這個項目時遇到的一些問題。
目標：像文件夾一樣顯示提交記錄
我做這個事的主要目的是給大家一些啟發：Git 核心是如何運行的。總結來說，Git 提交記錄實際上和文件夾非常類似 —— 每個 Git 提交都包含一個目錄，其中 列出了文件，這個目錄也可以有子目錄，依此類推。
只是為了節省磁盤空間，Git 提交實際上并不是以文件夾的形式實現的。
而在 git-commit-folders，所有的提交記錄實際上看起來就是一個文件夾，如果你想瀏覽歷史提交記錄，你可以像瀏覽文件系統一樣瀏覽它們！例如如果你像查看我的博客的初始提交記錄，你可以如下操作：
$ ls commits/8d/8dc0/8dc0cb0b4b0de3c6f40674198cb2bd44aeee9b86/
README其他之后的提交記錄，如下：
$ ls /tmp/git-homepage/commits/c9/c94e/c94e6f531d02e658d96a3b6255bbf424367765e9/
_config.yml config.rb Rakefile rubypants.rb source分支是符號鏈接
通過 git-commit-folders 掛載的文件系統中，提交是唯一真正的文件夾 —— 其他一切（分支、標簽等）都是提交記錄的符號鏈接。這反映了 Git 底層的工作方式。
$ ls -l branches/
lr-xr-xr-x 59 bork bazil-fuse -> ../commits/ff/ff56/ff563b089f9d952cd21ac4d68d8f13c94183dcd8
lr-xr-xr-x 59 bork follow-symlink -> ../commits/7f/7f73/7f73779a8ff79a2a1e21553c6c9cd5d195f33030
lr-xr-xr-x 59 bork go-mod-branch -> ../commits/91/912d/912da3150d9cfa74523b42fae028bbb320b6804f
lr-xr-xr-x 59 bork mac-version -> ../commits/30/3008/30082dcd702b59435f71969cf453828f60753e67
lr-xr-xr-x 59 bork mac-version-debugging -> ../commits/18/18c0/18c0db074ec9b70cb7a28ad9d3f9850082129ce0
lr-xr-xr-x 59 bork main -> ../commits/04/043e/043e90debbeb0fc6b4e28cf8776e874aa5b6e673
$ ls -l tags/
lr-xr-xr-x - bork 31 Dec 1969 test-tag -> ../commits/16/16a3/16a3d776dc163aa8286fb89fde51183ed90c71d0這個并不能完全呈現 Git 的所有工作機理（相比簡單的類似文件夾的提交，還有很多復雜的細節），但是我希望大家對“每個提交如同一個文件夾，里面有你的舊版本代碼”有一個直觀的認識。
這么做有什么好處呢？
在我深入介紹它的實現之前，我想說下為什么把 Git 提交記錄變成擁有文件夾的文件系統很有用。我的很多項目最終都沒有真正使用過（比如 dnspeep），但我發現自己在做這個項目的時候確實使用到了一些。
目前為止我發現主要用處是：
- 查找已經刪除的函數 - 可以用
grep someFunction branch_histories/main/*/commit.go查找它的舊版本 - 快速查看其他分支的一個文件并從其拷貝一行，如
vim branches/other-branch/go.mod - 在每個分支中搜索某個函數，如
grep someFunction branches/*/commit.go
所有這些操作都通過提交記錄的符號鏈接，來替代提交記錄的直接引用。
這些都不是最有效的方法（你可以用 git show 和 git log -S 或者 git grep 來完成類似操作），但是對我個人來說，我經常忘記 Git 語法，而瀏覽文件系統對我來說更簡單。git worktree 還允許你同時簽出多個分支，但對我來說，為了看一個文件而設置整個工作樹感覺很奇怪。
接下來我想談談我遇到的一些問題。
問題 1: 用 WebDav 還是 NFS?
Mac OS 原生支持的兩個文件系統是 WebDav 和 NFS。我說不出那個更新容易實現，所以我就索性嘗試兩個都支持。
起初，WebDav 的實現看起來更容易一些，在 golang.org/x/net 上有一個 WebDav 實現，這個很好配置。
但這個實現不支持符號鏈接，我想可能原因是它用的是 io/fs 接口，而 io/fs 還不支持 符號鏈接。不過看起來正在進行中。所以我放棄了 WebDav，而決定重點放在 NFS 實現上了，用 go-nfs NFSv3 的庫文件來實現。
有人也提到了 Mac 上的 FileProvider，我還沒有深入了解這個。
問題 2: 如何確保所有的實現保持一致？
我已經實現了三個不同的文件系統（FUSE、NFS 和 WebDav），但對我來說還是沒搞清楚如何避免大量的重復代碼。
我的朋友 Dave 建議寫一個核心實現，然后寫一個適配器（如 fuse2nfs 和 fuse2dav）來轉換成 NFS 和 WebDav 版本。這個看起來需要我著手實現三個文件系統的接口：
- 對應 FUSE 的
fs.FS - 對應 NFS 的
billy.Filesystem - 對應 WebDav 的
webdav.Filesystem
因此我把所有的核心邏輯放到 fs.FS 接口上，然后寫兩個函數：
func Fuse2Dav(fs fs.FS) webdav.FileSystemfunc Fuse2NFS(fs fs.FS) billy.Filesystem
所有的文件系統都比較類似，因此轉換起來不是很難，但就是有大量的煩人的問題需要修復。
問題 3: 我不想羅列所有的提交記錄怎么辦
一些 Git 存儲庫有成千上萬的提交記錄。我的第一個想法是如何讓 commits/ 看起來是空的，這樣就可以如下展示：
$ ls commits/
$ ls commits/80210c25a86f75440110e4bc280e388b2c098fbd/
fuse fuse2nfs go.mod go.sum main.go README.md因此所有的提交記錄可以直接查看，但是又不能羅列它們。這個對文件系統是一個奇怪的事情，實際上 FUSE 可以做到。但我在 NFS 上無法實現。我認為這里的原因是，如果你告訴 NFS 某個目錄是空的，它就會認為該目錄實際上是空的，這是合理的。
我們最終是這樣處理的：
- 按照
.git/objects的方式，以前兩個字符組織管理提交記錄（因此ls commits會顯示0b 03 05 06 07 09 1b 1e 3e 4a），但這樣做會分為兩層，這樣18d46e76d7c2eedd8577fae67e3f1d4db25018b0則為commits/18/18df/18d46e76d7c2eedd8577fae67e3f1d4db25018b0 - 開始只羅列一次所有的已經打包的提交哈希，將它們緩存在內存中，然后后面僅更新稀疏對象。主要思路是版本庫中幾乎所有的提交都應該打包，而且 Git 不會經常重新打包提交
這個看起來在擁有百萬提交記錄的 Linux 內核的 Git 存儲庫上似乎效果不錯。在我的機器上實測它初始化大概需要一分鐘，之后只需快速增量更新即可。
每個提交哈希只有 20 個字節，因此緩存 1 百萬個提交哈希也不是很大，大約 20MB。
我認為更聰明的做法是延遲加載提交列表 —— Git 會按提交 ID 對其打包文件進行排序，所以你可以很容易地進行二叉樹搜索，找到所有以 1b 或 1b8c 開始的提交。我用的 Git 庫 對此并不支持，因為羅列出來 Git 存儲庫所有的提交記錄確實一個奇怪的事情。我花了 幾天時間 嘗試實現它，但沒有達到我想要的性能，所以就放棄了。
問題 4: 不是目錄
我常遇到下面這個錯誤：
"/tmp/mnt2/commits/59/59167d7d09fd7a1d64aa1d5be73bc484f6621894/": Not a directory (os error 20)這起初真的把我嚇了一跳，但事實證明，這只是表示在列出目錄時出現了錯誤，而 NFS 庫處理該錯誤的方式就是顯示 “Not a directory”（不是目錄）。這個錯誤遇到了很多次，我需要每次跟蹤這個錯誤的根源。
有很多類似錯誤。我也遇到 cd: system call interrupted，令人沮喪的是，但最終也只是程序中的其他錯誤。
我意識到終極大法是用 Wireshark 查看 NFS 發送和接受的數據包，很多問題便可迎刃而解。
問題 5: inode 編號
在開始的時候我不小心將所有的文件夾的 inode 設為 0。這很糟糕，因為如果在每個目錄的 inode 都為 0 的目錄上運行查找，它就會抱怨文件系統循環并放棄，這個也是符合邏輯的。
我通過定義一個 inode(string) 來修復這個問題，通過散列字符串來獲取 inode 編號，并使用樹 ID / blob ID 作為散列字符串。
問題 6: 過期文件句柄
我一直遇到這個“Stale NFS file handle”（過期文件句柄）錯誤。問題是，我需要獲取未知的 64 字節 NFS “文件句柄”，并將其映射到正確的目錄。
我使用的 NFS 庫的工作方式是為每個文件生成一個文件句柄，并通過固定大小的緩存來緩存這些引用。這對小型存儲庫來說沒問題，但是如果對于擁有海量的文件的存儲庫來說，由于緩存就會溢出，就會導致“stale file handle” 錯誤。
這仍然是個問題，我不知道如何解決。我不明白真正的 NFS 服務器是如何做到這一點的，也許它們只是有一個非常大的緩存？
NFS 文件句柄占用 64 個字節（不是比特），確實很大，所以很多時候似乎可以將整個文件路徑編碼到句柄中，根本不需要緩存。也許我會在某個時候嘗試實現這一點。
問題 7: 分支歷史
branch_histories/ 目錄目前僅羅列對應分支的最近 100 個提交記錄。我不知道該怎么做，如果能以某種方式列出分支的全部歷史就更好了。也許我可以使用 commits/ 目錄中類似的子文件夾技巧。
問題 8: 子模塊
Git 存儲庫有時包含了子模塊。由于目前我對子模塊的理解還不深入，我先忽略它吧。因此這個算是一個問題。
問題 9: NFSv4 是否更好？
我構建這個項目使用的是 NFSv3 庫，因為我當時只能找到一個 NFSv3 的 Go 庫文件。可當我搞完的時候才發現了一個名叫 buildbarn 的項目里有 NFSv4 服務器。有沒有可能用它會更好一些？
我不知道這樣做有什么問題，或者用 NFSv4 有哪些優點？我還有點不確定是否要使用 buildbarn NFS 庫，因為不清楚他們是否希望其他人使用它。
就這些吧
之前已經解決了很多問題我都忘記了，這是我目前能回想起來的。我未來有可能解決或根本解決不了 NFS 的“過期文件句柄” 錯誤，或者“在 Linux 內核的存儲庫上啟動需要 1 分鐘”的問題，就這樣吧。
感謝我的朋友 vasi，他給我了很多文件系統方面的幫助。
