总结：我正在使用带有--reference的git clone到一个存储库，该存储库包含所有相应的文件但不包含提交，我希望它能节省网络带宽和磁盘空间。它没有。
我正在从SVN转换存储库。我做了一个
cd DIR1; git svn clone $REPO
然后我为$ REPO设置了subgit（非常好，BTW）。 Subgit创建完全不同的提交，因为提交消息不同，但文件都是相同的。
然后我做了一个：git clone --reference DIR1 $SUBGITREPO DIR2
我希望它能获取所有提交对象，但是从DIR1引用文件和目录。它没有那样做 - 它将完整的文件传输到DIR2。
结账后我使用git ls-tree验证是，在DIR1和DIR2中，文件的SHA1 相同。
那么，为什么git没有做我期望的事情，我怎么能这样做呢？
对我来说，制作一个新的克隆并不是什么大不了的事，但太平洋地区的人们希望能节省一些网络......
TIA
答案 0 :(得分：1)
git的--reference标志用于共享 git 数据（版本控制，树，提交下的文件内容）。目录中包含的工作空间（即“可见文件”）（或者如果它们存在）完全不相关。
答案 1 :(得分：0)
鉴于存在所有引用文件/目录的git对象，是否有任何方法可以加快结帐速度？
检查Git 2.23（Q3 2019）是否可以改善问题及其性能，因为备用对象存储库中的引用提示现在可以用作可到达性计算的起点。
请参见commit 39b44ba的commit 709dfa6，Jeff King (peff)（2019年7月1日）。
（由Junio C Hamano -- gitster --在commit 68e65de中合并，2019年7月19日）
check_everything_connected：假设其他参考提示有效当我们收到对sha1“
X”的远程引用更新时，我们要检查 我们拥有“X”所需的所有对象。我们可以假设我们的存储库当前未损坏，因此，如果我们有一个指向“
Y”的引用，则我们拥有其所有对象。
因此我们一点击“X”就可以停止从“Y”开始遍历。如果我们对用于存储备用数据库的任何存储库做出相同的不腐败假设，那么我们还可以使用其引用提示来缩短遍历。
这在使用“
--reference”进行克隆时特别有用，因为 否则，没有任何本地裁判可以检查，并且必须 纵览整个历史，即使对方可能已经送我们 很少或没有物体。以下是所包含的性能测试的结果（它或多或少地显示出最大的节省量，进行一次新提交并共享整个历史记录）：
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%