摘要：我将 git clone 与 --reference 一起使用到具有所有适当文件但没有提交的存储库，我希望它可以节省网络带宽和磁盘空间。它没有。
我正在从 SVN 转换存储库。我做了一个
cd DIR1; git svn clone $REPO
然后我为 $REPO 设置了 subgit（非常好，顺便说一句）。Subgit 创建完全不同的提交，因为提交消息不同但文件都相同。
然后我做一个：
git clone --reference DIR1 $SUBGITREPO DIR2
我期待它获取所有提交对象，但从 DIR1 引用文件和目录。它不会那样做——它将完整的文件传输到 DIR2 中。
结帐后，我使用 git ls-tree 验证是的，文件的 SHA1在 DIR1 和 DIR2 中是相同的。
那么，为什么 git 不按我的预期做，我怎样才能做到呢？
制作一个新的克隆对我来说没什么大不了的，但是太平洋彼岸的人们希望节省一些网络费用……
TIA
git的--reference标志用于共享git数据（版本控制下的文件内容、树、提交）。目录中的工作空间（即“可见文件”）包含什么（或者它们是否存在）完全无关紧要。
鉴于所有引用文件/目录的 git 对象都存在，有什么方法可以加速结帐？
检查 Git 2.23（2019 年第三季度）是否改进了该问题及其性能，因为来自备用对象存储的 refs 的提示现在可以用作可达性计算的起点。
请参阅Jeff King ( ) 的提交 39b44ba和提交 709dfa6（2019 年 7 月 1 日）。（由Junio C Hamano 合并 -- --在提交 68e65de中，2019 年 7 月 19 日）peff
gitster
check_everything_connected：假设备用参考提示是有效的当我们收到对 sha1 "
X" 的远程 ref 更新时，我们想要检查我们是否拥有 "X" 所需的所有对象。我们可以假设我们的存储库当前没有损坏，因此如果我们有一个指向“
Y”的 ref，我们就有了它的所有对象。
所以我们可以在X点击“”时停止从“”开始的遍历Y。如果我们对用于存储替代品的任何存储库做出相同的非损坏假设，那么我们也可以使用它们的 ref 提示来缩短遍历。
这在使用 "" 进行克隆时特别有用
--reference，因为否则我们没有任何本地 refs 可以检查，并且必须遍历整个历史记录，即使对方可能发送给我们的对象可能很少或没有。以下是包含的性能测试的结果（它或多或少地展示了最大的节省，获得了一个新的提交并共享了整个历史记录）：
Test HEAD^ HEAD
--------------------------------------------------------------------
[on git.git]
5600.3: clone --reference 2.94(2.86+0.08) 0.09(0.08+0.01) -96.9%
[on linux.git]
5600.3: clone --reference 45.74(45.34+0.41) 0.36(0.30+0.08) -99.2%