Git repo从一个位置复制到另一个位置，Git pull现在报告不同的计数

我有一个git repo，通过Windows 10文件资源管理器从磁盘复制到外部硬盘

然后，我在源目录和目标目录中打开了一个git shell，并称之为“git pull”。他们的行为应该是一样的，但事实并非如此

源目录：

urban@NBURBAN MINGW64 /t (Master)
$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Counting objects: 79623, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (48167/48167), done.
Writing objects: 100% (79623/79623), done.
Total 79623 (delta 41438), reused 52322 (delta 26522)
Removing duplicate objects: 100% (256/256), done.
Already up-to-date.

urban@NBURBAN MINGW64 /d/Backup-20171215 (Master)
$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Counting objects: 79623, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (48167/48167), done.
Writing objects: 100% (79623/79623), done.
Total 79623 (delta 41436), reused 52323 (delta 26522)
Removing duplicate objects: 100% (256/256), done.
Checking connectivity: 79623, done.
Already up-to-date.

目标目录：

urban@NBURBAN MINGW64 /t (Master)
$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Counting objects: 79623, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (48167/48167), done.
Writing objects: 100% (79623/79623), done.
Total 79623 (delta 41438), reused 52322 (delta 26522)
Removing duplicate objects: 100% (256/256), done.
Already up-to-date.

urban@NBURBAN MINGW64 /d/Backup-20171215 (Master)
$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Counting objects: 79623, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (48167/48167), done.
Writing objects: 100% (79623/79623), done.
Total 79623 (delta 41436), reused 52323 (delta 26522)
Removing duplicate objects: 100% (256/256), done.
Checking connectivity: 79623, done.
Already up-to-date.

---

您是否注意到“增量”和“重用”计数的微小差异？考虑到两个目录的起始状态应该相同，这怎么可能呢？

还添加了一个

检查连接：

行

但是，考虑一下，您没有运行

git gc

，而是运行

git pull

，它本身运行

git fetch

，然后是第二个git命令，通常是

git merge

。所有这些都或多或少是同时发生的（好吧，

gitpull

运行的两个Git命令是顺序的，但是后台的

gitgc

与这两个命令并行运行）

由于前台操作获取和合并会创建Git对象，因此如果后台操作和前台操作的速度之间存在细微的时间差异，则可以很容易地获得不同的对象计数。最初计算所有匹配项，所以这里可能不是这样，但这是一种可能性，所以值得一提

同时，

git gc

允许操作的特定对象（包括“用压缩对象替换松散对象”和“完全删除”）以及delta链的顺序等项至少可能受到文件时间戳的影响。如果您复制一个满是文件的目录，新文件通常会打上“now”的时间戳。1它没有提到文件的mtime，但将Git源代码灰显为

mtime

会显示文件统计mtime字段确实进入了一些相关计算

您可以尝试一些更仔细控制的实验，其中复制保存所有文件元数据的文件树，并直接运行

git gc

（而不是

--auto

，并且不同时运行任何其他git操作）。我认为观察到的差异将消失

---

---

1我不知道这种特殊的复制方法（通过Windows 10文件资源管理器）是否保留时间戳。

还添加了一行检查连接：

但是，考虑一下，您没有运行

git gc

，而是运行

git pull

，它本身运行

git fetch

，然后是第二个git命令，通常是

git merge

。所有这些都或多或少是同时发生的（好吧，

gitpull

运行的两个Git命令是顺序的，但是后台的

gitgc

与这两个命令并行运行）

由于前台操作获取和合并会创建Git对象，因此如果后台操作和前台操作的速度之间存在细微的时间差异，则可以很容易地获得不同的对象计数。最初计算所有匹配项，所以这里可能不是这样，但这是一种可能性，所以值得一提

同时，

git gc

允许操作的特定对象（包括“用压缩对象替换松散对象”和“完全删除”）以及delta链的顺序等项至少可能受到文件时间戳的影响。如果您复制一个满是文件的目录，新文件通常会打上“now”的时间戳。1它没有提到文件的mtime，但将Git源代码灰显为

mtime

会显示文件统计mtime字段确实进入了一些相关计算

您可以尝试一些更仔细控制的实验，其中复制保存所有文件元数据的文件树，并直接运行

git gc

（而不是

--auto

，并且不同时运行任何其他git操作）。我认为观察到的差异将消失

---

---

1我不知道这种特殊的复制方法（通过Windows 10文件资源管理器）是否保留了时间戳。

从直接问答的角度来看，我认为torek对这种情况的发生有最合理的解释。我不认为它适用于这里，但对更一般的“这怎么可能？”问题的另一个想法是，一些详细的诊断（涉及gc）也可能仅仅因为命令运行的时间而改变（例如，reflog expiration的bc）。这让我想到了真正的问题。。。。。。在我看来，更有趣的问题是，这有关系吗（如果有，为什么）？这些诊断对最终用户来说并没有多大意义，正如所指出的，许多小因素可能以看似任意的方式改变它们。如果您只是想验证备份是否完整且未损坏，请检查每个引用的哈希值。如果它们匹配（并且在repo中没有损坏，这可能是通过git fsck检测到的），则备份是完整且正确的。从直接问答的角度来看，我认为torek对这种情况的发生有最合理的解释。我不认为它适用于这里，但对更一般的“这怎么可能？”问题的另一个想法是，一些详细的诊断（涉及gc）也可能仅仅因为命令运行的时间而改变（例如，reflog expiration的bc）。这让我想到了真正的问题。。。。。。在我看来，更有趣的问题是，这有关系吗（如果有，为什么）？这些诊断对最终用户来说并没有多大意义，正如所指出的，许多小因素可能以看似任意的方式改变它们。如果您只想验证备份是否完整且未损坏，请检查每个引用的哈希值。如果它们匹配（并且在repo中没有损坏，这可能是通过git fsck检测到的），则备份是完整且正确的。