git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

[weishao666]

git fork 一个 200M 的仓库 A ，得到 B ，我在 B 的裸库查看大小 du -sh ，可以看到是 200M ，但是我整个磁盘的大小并不会增加 200M ，机会没变化。这是 git 的什么机制做到的呢？假如我把 B copy 到/tmp/B ，那磁盘就增加了 200M ，又是什么原理？肯定跟底层的文件引用啥的有关系，但是我在 B 的裸库中并没有见到软链接

[e3c78a97e0f8]

本地的 git clone 就是硬链接

[atuocn]

@ysc3839 github 如何实现内部存储的是个黑匣子，既然它说了 fork 是个 copy, 用起来也像个 copy （你提到的 commit 查询，只是 github 页面上的功能，本地应该是查不到的），那对我们来说就是一个 copy.

另外，我登入到 gitlab 的 server 上看了一下，它的 git 仓库就是一个一个的目录.

[atuocn]

好吧，33 楼给了答案。gitlab 使用了 git alternates 机制

At the Git level, we achieve deduplication by using Git alternates. Git alternates is a mechanism that lets a repository borrow objects from another repository on the same machine.

[Shatyuka]

https://imgur.com/a/DVOBXf7

[Shatyuka]

[proxychains]

@Shatyuka #45 哈哈哈哈哈哈哈哈哈

[mxT52CRuqR6o5]

压根就没人说过 fork 是个 copy, 实际用起来也不像 copy
依赖文件系统的 link 能力去管理重复文件非常地工程实践层面的不合理，如果文件系统不支持 link 那我 git 服务岂不是还部署不上去了？如果不同文件系统的 link 行为不一致，那我写实际业务代码时还得去考虑这些区别？压根儿就不应该往文件系统 link 这个方向去思考，在 git 自身已经提供了复用相同文件的机制的情况下，任何不借助 git 自身能力去管理重复文件的实践都是不合理的，完全属于画蛇添足脱裤子放屁的行为