我在这里寻找有关更快地将批量文件导入git repo的启发，但不确定是这样。
基本上情况是，我有超过1亿个文件要提交到git repo。我已经将它们分解成大约5个深度的目录。在git add path/2/3某种程度上，深度大约需要5分钟。然后提交，然后发布。提交所有这些文件需要很长时间，并且可能要花费数月的时间。
请不要怀疑为什么我将它们存储在git中，以及它们是否是源文件以及是否有更好的解决方案等。我特别想知道git可以处理多少以及是否可以处理此问题。以更优化的方式处理许多文件。
仅供参考，这些都是配置文件或类似CSV的数据文件，有些很大，大多数很小。
如果我尝试提交全部内容或只是一个较大的片段，则可能需要一个小时才能全部提交。但是要发布它可能要花几个小时，而我已经尝试过了，而且经常互联网中断和繁荣时，您必须重新开始。因此，我认为这不是可行的解决方案。
我想知道的是，是否有一种方法可以一口气将所有这些东西直接加载到git中，就像您将通过数据库转储将其加载到数据库中一样，并且绕开提交时所做的所有git东西。然后，它创建一个提交。然后以某种方式像rsync一样发布，它会在功能强大且不会中断Internet连接的情况下中断。然后，这就像正常上传。
Git数据库可以存储的文件数量（严格来说是Blob对象）几乎没有硬性限制。1不过，还有一些较软的限制。
我有两个相当大的存储库-FreeBSD和Linux-分别拥有5.7和670万个对象。这远远少于1亿个文件：Linux存储库的大小约为该文件大小的1/15，即使那样，文件数量也不是很多，因为许多对象是提交和树。
请注意，将1亿个文件放入一个提交和将1亿个文件放入1亿个提交之间是有区别的，每个提交都存储一个文件。前者将需要建立一个索引，该索引列出1亿个文件，这是索引文件的几GB，并且可能很慢，但随后将存储1亿个Blob，每个目录再加上一个树对象，再加上一次提交。后者将建立一个小的索引（包含1个文件），使用一棵持有一个blob的树进行一次提交，然后重复1亿次：索引永远不会很大，但是存储库将存储3亿个对象：1亿个提交，每个提交1棵树和1个斑点。
一直到哪里都不是很明显。git add <path>要求：
索引已排序，因此可以想象此更新非常快-如果新文件位于索引的末尾，则只需一个字节但又多的字节追加就足够了-或令人难以置信的是：在前面的插入为O（n 2）关于索引中已有条目的数量，因为所有条目都必须向下移动。实际上，Git将索引读入内存，在其中执行操作，然后将索引写回，因此，一旦索引超过某个大小阈值（取决于操作系统和底层存储介质类型/速度而定），它可能会非常慢。 ）。
打包对象之间可能还需要大量磁盘空间。Modern Git将git gc --auto在每次提交后运行，但是在早期Git和2.17.0（已修复）之间运行，git commit偶然没有。考虑到您的情况，您可能git gc仍要禁用自动功能，并以可控制的时间间隔运行它，或者如您所链接的文档中所述，用于git fast-import构建打包文件而无需通过常规的Git渠道。这将避免对完全索引的需要（直到运行git checkout到提取这些提交的一个，那就是）。
1唯一真正的硬限制是只有2 160个可能的哈希ID。但是，当您达到约1.7万亿个对象时，您会遇到显着高的哈希冲突概率，大约为10 -18中的1（这也是许多磁盘制造商引用的未校正误码率）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句