我一直在嘗試跟蹤我的 VM 狀態，以便我可以隨時恢復到舊版本，以防我在測驗程序中搞砸了。
假設我進入了目錄，做了git init; git add .; git commit -m 'restore point'.
最初，我有一個名為 Tiny10.vmdk 的檔案，其大小約為 19GB，然后我將其重命名為 Tiny10_old.vmdk。現在我想我們可以假設 Tiny10.vmdk 不再在 git 記錄的作業目錄中。所以我嘗試了：
git restore Tiny10.vmdk
還原更改
但是，我發現新的 Tiny10.vmdk 現在只有 2GB，而且肯定已經損壞。
這是怎么發生的？它是一個錯誤嗎？
git 對它可以跟蹤的檔案有大小限制嗎？
我該如何解決？
從一開始就跟蹤 .vmdk 檔案是個好主意嗎？
PS：.vmdk 是 VMware 虛擬磁盤檔案的縮寫
用于重現錯誤的腳本
git init
git add .
git commit -m 'restore point'
mv Tiny10.vmdk Tiny10_old.vmdk
git restore Tiny10.vmdk
uj5u.com熱心網友回復：
由于各種原因，Git 通常不會損壞檔案——但 Git可能會遇到其自身的限制。特別是 2GB 和 4GB 大小數字在某些 32 位機器上相當神奇，可能包括您的 Windows 系統。如果是這種情況，您將需要不同版本的 Git 和/或不同的作業系統。
血腥細節
Git 主要是用 C 語言撰寫的。1 C 有一些簡單的基本資料型別：char, short, int, long, 以及自 1999 年以來的long long, 以及可應用于這些型別的有符號和無符號限定符。從這些 C 型別中的每一種到機器級硬體指令沒有規定char的映射，但是這里有一組非常常見的原則可以用來避免意外：（及其有符號和無符號變體）映射到一個 8 位位元組，它只能存盤從 0 到 255 的值（或 -128 到 127 包括在有符號時），short映射到范圍為 0 到 65535 或 -32768 到 32767 的 16 位“短字”，int映射到 16、32 或 64少量，long至少是 32 位型別，范圍從 0 到 4294973647 或 -2147483648 到 2147483647，并且，如果它存在于您的實作中，它是從 0 映射到 2 64 -1 或 -2 63到 long long的 64 位型別2 63 -1。2
Git 使用的 C 代碼在很長一段時間內都是 C99 之前的代碼，并且避免直接使用long long. for我認為現在終于放寬了（盡管仍在避免其他 C99 匯入，例如回圈內的宣告），但如果我們確實避免long long并在 處最大long，則最大可能為 4 GB（4294973647 或 0xFFFFFFFF）。簽名后，它可能最大為 2 GB。將 1 添加到unsigned long保持最大可能值會產生一個保持零的變數（換句話說，我們期望的通常的有限域算術結果）。當使用有符號數時，C 并沒有規定我們是否得到這種環繞，或者溢位陷阱，或者“粘性”算術，或者其他什么，但是為了與流行的實作兼容，我們通常會看到相同型別的環繞，所以 2147483647 1 等于 -2147483648（0x7FFFFFFF 1 = 0x80000000，然后將其視為最負的二進制補碼值）。
當基于 C 的 Git 實作具有這些 32 位限制時，可能的最大檔案大小為 2 GB 或 4 GB（減一），具體取決于檔案大小是存盤在有符號整數還是無符號整數中。理想情況下，Windows 系統上的 C Git 至少應該注意到某些檔案比它可以存盤的大，并給你一個錯誤，而不是使用它的大小 mod 2 31或 2 32并使用它并假裝一切都很好。您可能會考慮將此作為針對您特定 Windows 版本 Git 的錯誤提交。
1有一個 JGit Java 版本和一個 Go 版本，顯然還有一個發生在 Rust 和可能其他語言中。但是 Git-for-Windows 和不合格的“Git”往往指的是 C 版本。 每個版本都有自己的怪癖，所以如果您遇到怪癖并且您可能正在使用 C Git 以外的其他東西，請找出您正在使用的特定版本。即使你使用的是 CGit，它也有很長的歷史，各種版本都有各種錯誤，所以看看你使用的是什么版本。
2我是憑記憶輸入的，在輸入時沒有仔細看，所以要小心拼寫錯誤。使用二進制計算器查找 2 32等以仔細檢查確切值。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/483505.html
標籤：混帐
上一篇：GIT中提交的父母和孩子的數量