稀疏結帳 - 它是如何工作的

Question

我一直在尋找一種方法來只克隆我的一個項目的子目錄。 顯然我找到了這個答案。 它設計精良，分步解決方案很好地解釋了如何實施。 現在最后它引用了說明這一點的文檔：

“稀疏結帳”允許稀疏地填充工作目錄。 它使用 skip-worktree 位（參見 git-update-index(1)）來告訴 Git 工作目錄中的文件是否值得查看。

我的問題是我不明白這是什么意思。 我從 Git 學到的一件事是，它是一個很棒的工具，但在實施某件事之前，了解幕后發生的事情從長遠來看確實對你有幫助。

所以，這是一個問題：

稀疏結帳如何工作以及 output 是什么？

Answer 1

新的git sparse-checkout命令（在 Git 2.25（2020 年第一季度）中引入）來自 Microsoft 基於其Scalar項目的貢獻

在 Microsoft，我們支持Windows 操作系統存儲庫使用VFS for Git （以前稱為 GVFS）。 Git 的 VFS 使用虛擬化文件系統繞過許多關於存儲庫大小的假設，使 Windows 開發人員能夠以以前認為不可能的規模使用 Git。

在為 Git 支持 VFS 的同時，我們使用自定義跟蹤系統並收集用戶反饋來確定性能瓶頸。
我們對 Git 客戶端做出了多項貢獻，包括提交圖文件以及對git push和sparse-checkout改進。

基於這些貢獻和對 Git 的許多其他近期改進，我們開始了一個項目來支持非常大的存儲庫，而無需虛擬化文件系統。

因此， Scalar 項目已從 Git 的VFS修改版本（2021 年中）過渡到圍繞核心 Git 功能的精簡版 shell。
Scalar 可執行文件現已移植到包含在microsoft/git fork中。

它與Git 集成為 Windows 2.38 （2022 年 10 月）

Derrick Stolee的 2020 年文章“ 通過稀疏結賬縮小你的 monorepo 的規模”解釋了當今如何管理稀疏結賬（2020+）

對現有存儲庫使用sparse-checkout

要將您的工作目錄限制為一組目錄，請運行以下命令：

 git sparse-checkout init --cone git sparse-checkout set <dir1> <dir2>...

如果遇到問題，請運行git sparse-checkout disable以返回完整的工作目錄。

init子命令設置必要的 Git 配置選項，並用表示“僅匹配根目錄中的文件”的模式填充sparse-checkout文件。

set子命令使用模式修改sparse-checkout文件以匹配給定目錄中的文件。
此外，還包括直接位於指定目錄的父目錄中的任何文件。

例如，如果您運行git sparse-checkout set A/B ，則 Git 將包含名稱為A/B/C.txt （ A/B ）和A/D.txt （ A/B的直接兄弟級）的文件) 以及E.txt （ A直接兄弟）。

例如：

構建 Android 應用程序的團隊通常可以只使用client/android中的文件，並使用當前部署的服務運行所有集成測試。

Android 團隊在工作時需要的文件集要小得多。
這意味着他們可以使用git sparse-checkout set命令限制到該目錄：

$ git sparse-checkout set client/android

$ ls
bootstrap.sh*  client/  LICENSE.md  README.md

$ ls client/
android/

$ find . -type f | wc -l
62

---

git sparse-checkout自 Git 2.32（2021 年第一季度）起使用稀疏索引。
請參閱Derrick Stolee的文章“ 使用 Git 的稀疏索引讓你的 monorepo 感覺很小”。

稀疏索引在一個方面不同於普通的“完整”索引：它可以為其樹 object 存儲 ID 為 object 的目錄路徑。

這是與 blob 對象配對的文件路徑的補充。

由於錐形模式稀疏檢出模式在目錄級別匹配，我們可以確定整個目錄在稀疏檢出錐之外，並將其包含的所有文件路徑替換為單個目錄路徑。

稀疏目錄條目對應於稀疏結帳定義之外的目錄。
這些目錄還有一個緩存樹節點，其范圍只有一個條目：稀疏目錄條目。

---

Git 2.36（2022 年第 2 季度）、“ git update-index ” ^{（ man ）} 、“ git checkout-index ” ^{（ man ）}和“ git clean ” ^{（ man ）}被教導可以更好地使用稀疏結帳功能。

請參閱Victoria Dye ( vdye )的提交b9ca5e2 、提交c35e9f5 、 提交 e015d4d 、 提交 35682ad 、 提交 88078f5 、 提交 b553ef6 、 提交 1e9e10e 、 提交 1624333 、 提交 bb01b26 （2022 年 1 月 11 日）。
^{（由Junio C Hamano 合並gitster 提交 2f45f3e ，2022 年 2 月 17 日）}

update-index ：與稀疏索引集成

^{簽字人：Victoria Dye
審核人：Elijah Newren}

通過update-index啟用稀疏索引。
update-index的大多數變體無需顯式擴展索引或在update-index.c之內或之外進行任何其他更新即可工作。

需要額外更改的一種用法是--cacheinfo ； 如果指定了稀疏目錄中的文件，則在緩存樹失效之前不會擴展索引，從而導致索引和緩存樹之間不匹配。
這種情況通過重新安排add_index_entry_with_check來處理，允許index_name_stage_pos在嘗試使相關緩存樹路徑無效之前擴展索引，從而避免緩存樹/索引損壞。

---

使用 Git 2.36（2022 年第 2 季度），更好地控制了 git 稀疏結帳錐形模式。

請參閱Elijah Newren ( newren )的提交 8dd7c47 、 提交 4ce5043 、 提交 bb8b5e9 、 提交 d526b4d 、 提交 f748012 （2022 年 2 月 19 日）。
^{（由Junio C Hamano 合並gitster 提交 9671764，2022年 3 月 6 日）}

sparse-checkout ：拒絕 arguments 看起來像模式的錐形模式

^{審核人：Derrick Stolee
簽字人：Elijah Newren}

在cone模式下的sparse-checkout add/set中，傳遞的 arguments 應該是目錄而不是gitignore-style模式。

然而，考慮到在手動討論模式上花費的精力，用戶很容易假設他們需要傳遞模式，例如

/foo/*

或者

!/bar/*/

或者他們可能真的忽略了目錄規則並指定了一個隨機的gitignore-style模式，比如

*.c

為了幫助捕獲此類錯誤，如果位置 arguments 中的任何一個都拋出錯誤：

 * starts with any of '/?' * contains any of '*?[]'

通知用戶他們可以通過--skip-checks如果他們有一個目錄確實在其名稱中有這樣的特殊字符。
（我們排除 '' 是因為稀疏結帳對反斜杠的特殊處理；請參閱t1091.46 中的 MINGW 測試。 ）

而且，仍然是 2.36：

隨着 Git 2.36（2022 年第二季度），進一步完善 git 稀疏結賬”。

請參閱Elijah Newren ( newren )的提交 8dd7c47 、 提交 4ce5043 、 提交 bb8b5e9 、 提交 d526b4d 、 提交 f748012 （2022 年 2 月 19 日）。
^{（由Junio C Hamano 合並gitster 提交 9671764，2022年 3 月 6 日）}

sparse-checkout : 注意 {set, add} 的前綴

^{幫助：Junio Hamano
審核人：Derrick Stolee
簽字人：Elijah Newren}

在cone模式下，非option arguments set&add顯然是path，所以要注意prefix。

在非錐形模式下，不清楚人們是否打算提供路徑，因為輸入是gitignore-style模式。
注意前綴會阻止人們做類似的事情

git sparse-checkout add /.gitattributes git sparse-checkout add '/toplevel-dir/*'

事實上，前者會導致

fatal: '/.gitattributes' is outside repository...

而后者將導致：

 fatal: Invalid path '/toplevel-dir': No such file or directory

盡管這兩者都是有效gitignore-style模式，如果將其添加到稀疏結帳文件中，將生成 select 個真實文件。

這可能會導致人們只使用沒有前導斜線的路徑，可能會導致他們在整個目錄層次結構中獲取具有相同名稱的文件，這與他們的預期相反。
另請參閱此線程和此線程。

添加前綴似乎充滿了錯誤； 因此，當從子目錄運行稀疏校驗設置/添加時，現在只需在非錐形模式下拋出一個錯誤。

Answer 2

提交指向一棵樹。 一棵樹描述了一個目錄，它指向其他樹，blob或提交。 其他樹是子目錄。 Blob是文件。 提交是子模塊。 不考慮子模塊， git checkout可以看作是將所有這些子目錄和文件從數據庫（在不可見目錄.git ）“復制”到工作區（默認情況下與.git處於同一級別）。 稀疏檢出僅復制某些子目錄或文件。 因此，稀疏簽出節省了工作區的空間。 數據庫占用的空間不會保存。