V2EX › mxT52CRuqR6o5 的所有回复 › 第 11 页 / 共 165 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 7 8 9 10 11 12 13 14 15 16 ... 165

❮

❯

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #21 难道你想要 git server 完全抛弃 blob 、pack 这些原生概念，设计一个不包含 blob 、pack 概念的存储系统？你也是有点离谱
但凡 git server 基于 blob 、pack 去进行存储，blob 和 pack 都没增加，我为啥还要考虑 git server 是怎么存储 blob 、pack 的，最重要的去重你说是在 blob 、pack 这个抽象层发生的还是在存储层发生的？除非你去设计一个命名存储的东西每增加，存储占用仍会大量增加的存储系统

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #18 我十分怀疑你还是没明白 OP 问的问题是什么，OP 是在服务器建了个 git server （ gitlab 这种），而不是在服务器 git clone 了一个仓库然后又复制了一份
什么叫「即使不是 blob 和 pack 存」，git 底层那些东西不就是 blob 、pack ，不存这些存什么，fork 一个仓库没增加 blob 、pack ，自然存储占用不会大幅增加

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #16 你说的这些不还是我最开始说的问题「干脆从 CPU 是怎么从沙子造出来开始解释好了」
hash 冲突这些不还是实现细节，而且还是 blob 、pack 实现的（必须处理的） edge case ，fork 一个仓库服务端存储没有大幅度增加，到底是因为 blob 、pack 的设计呢？还是因为你说的这些 edge case 呢？而且为啥你会假定 fork 一个仓库就非得把所有东西复制一遍再 gc ，不是很能理解
blob 、pack 的设计不就是 git 的基本原理的一部分吗？所以我说让 OP 去了解 git 的原理到底有什么问题？ fork 后服务端存储没有大幅度增加，blob 、pack 的设计就是最最最最主要的原因

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #14 服务器存 blob 和 pack 就行了，都不需要去重

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #12 fork 行为不增加 blob 和 pack ，基于此原理就能实现一个 fork 不增加存储占用的 git 服务，还有啥不够吗？你再往下深究什么软硬链接去重文件系统这个系统背后的细节具体是怎么设计的，不就是我之前说的干脆从 CPU 是怎么从沙子造出来开始解释好了
说得好像软硬链接文件去重我就不能继续往下深究一样，你咋不再往下解释解释软硬链接文件去重怎么就能节省存储空间了，为啥存储数据会增加存储空间，为啥磁盘会用容量上限，为啥磁盘能存储数据

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #8 fork 了又没增加新 blob 和 pack ，为啥会增长，为啥不能解释

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #6 一堆 blob 和 pack 对象还不够解释吗？你干脆从 CPU 是怎么从沙子造出来开始解释好了

252 天前

回复了 weishao666 创建的主题 › git › git fork 200M 的仓库，服务端磁盘占用并不会变大，是怎么做到的

@cc666 #6 一堆 blob 和 pack 对象还不够解释吗？

252 天前

回复了 drymonfidelia 创建的主题 › 程序员 › SHA256 末 8 位、SHA512 末 8 位、CRC32 全 8 位在对原文进行小幅修改后哪个更不容易无意重复？只有 8 位的情况下有意碰撞都很容易，因此不考虑有意碰撞的情况

我感觉 CRC32 最容易无意重复吧，修改正好抵消就重复了