我將完整的 Linux 核心 Git 歷史紀錄導入了 pgit

背景

這篇文章源於 pgit 開源專案的最新進展，作者嘗試將龐大的 Linux 核心 Git 歷史紀錄完整匯入 PostgreSQL 資料庫中。Linux 核心擁有超過 140 萬個提交紀錄與 20 年的開發歷史，傳統上僅有少數版本控制系統能處理如此規模的數據，而作者透過 pgit 證明了利用 SQL 資料庫進行深度歷史分析的可行性，並分享了匯入過程的效能數據與初步的 SQL 查詢發現。

社群觀點

Hacker News 的討論首先聚焦於標題的精確性，部分讀者指出「將 Linux 核心匯入資料庫」容易產生誤導，讓人誤以為是用資料庫來運行核心，而非儲存其 Git 歷史紀錄。儘管如此，社群對於將版本控制語義轉化為關聯式資料庫的嘗試展現出濃厚興趣。有留言提到，雖然 Git 目前佔據統治地位，但將版本控制數據儲存於資料庫並非首創，例如 Fossil 便是以 SQLite 為基礎構建，且 SQLite 專案本身也受益於這種「吃自家狗糧」的模式，為了追蹤提交歷史而開發出遞迴公用表運算式（Recursive CTEs）等功能。此外，也有人回憶起 Git 早期其實是受到 Monotone 的啟發，而 Monotone 同樣是使用 SQLite 儲存數據。

在技術實踐方面，社群成員分享了其他類似系統的運作方式。例如 Phabricator 在匯入儲存庫時也會將所有內容解析至 MySQL 中，藉此達成跨版本控制系統的無縫支援，並簡化網頁介面的開發。這類討論反映出開發者社群對於「版本控制數據化」的認可，認為這能讓原本難以進行的複雜分析，如檔案間的耦合度分析或貢獻者行為研究，變得如同執行 SQL 語法般簡單。

然而，這篇文章的寫作風格在社群中引發了不小的爭議。多位讀者強烈批評文章帶有濃厚的 AI 生成痕跡，認為過度修飾的語句與典型的 GPT 敘事節奏干擾了閱讀體驗，甚至有人表示因為無法忍受這種「LLM 贅言」而中途放棄閱讀。這引發了一場關於如何利用 AI 輔助寫作同時保有個人風格的討論，有經驗的用戶建議應提供個人寫作樣本讓 AI 學習語氣，以過濾掉那些機械化的罐頭修飾詞。儘管內容本身具有技術價值，但這種寫作風格的負面反饋顯示出技術社群對於 AI 生成內容的敏感度與排斥感。

延伸閱讀

在討論過程中，留言者提到了幾個與資料庫版本控制相關的資源。首先是 Fossil SCM，這是一個由 SQLite 團隊開發、完全基於 SQLite 的版本控制系統，其官方論壇也詳細記錄了如何利用 SQL 查詢檔案更名歷史的技術細節。另外，讀者也提到了 Monotone，這是一個對 Git 早期設計產生深遠影響的分散式版本控制系統，同樣採用了關聯式資料庫作為儲存後端。