相当于Mercurial在Git中的大文件扩展名？

Question

我正在将一些个人项目存储库从Mercurial迁移到Git。其中一个项目依赖于一些不变的，但是大型的shapefile和SQLite数据库。这些文件非常重要，需要存放在repo中，这样任何签出项目的人都可以访问它们。使用Mercurial，这很容易处理;我使用了largefiles扩展。 largefiles通过不尝试分析大于X的文件的内容来自动处理文件添加/更改。也就是说，我可以做hg addremove，一切都正常工作。

Git，就像Mercurial一样，不是为跟踪大文件而设计的。但是，我没有看到类似的扩展。我查看了git-annex，但似乎我需要手动跟踪文件（即，我不能随意做git add -A）。另外，如果我正确读到这一点，git-annex似乎在一个完全独立的回购中维护大文件。我想将当前仓库中的大文件保存在他们当前所在的目录中。

人们如何处理这种情况？当然，有很多项目需要跟踪项目运作中不可或缺的大型文件。请问git-annex能做到这一点，还是需要其他扩展？

Answer 1

唯一一个用于处理大型（甚至非常非常大）文件的类似git的系统是：

bup （请参阅GitMinutes #24）

中的详情

结果是一个实际的git repo，一个普通的Git命令可以读取。

我详细说明了 bup 与“git with large files”中Git的区别。

---

  

当然，有很多项目需要跟踪项目运作中不可或缺的大型文件。

不，没有。这根本不是Git的设计目标，甚至git-annex也是一种不完全令人满意的解决方法：参见“git-annex with large files”。 我在“How to handle a large git repository?”中提到了其他工具。

Answer 2

  

largefiles通过不尝试分析大于X的文件的内容来自动处理文件添加/更改。

这与core.bigFileThreshold有何不同？ -

  

core.bigFileThreshold

     

    

大于此大小的文件将以放气方式存储，而不会尝试增量压缩。在没有增量压缩的情况下存储大型文件可以避免过多的内存使用，但会增加磁盘使用量     所有平台上的默认值为512 MiB。对于大多数项目来说这应该是合理的，因为源代码和其他文本文件仍然可以进行增量压缩，但更大的二进制媒体文件不会。“

  

Answer 3

我跟踪大文件的md5哈希，而不是文件本身。我还有一个脚本，可以下载并下载存储库中跟踪的大文件。

我确信有比这更好的方法，但它适用于紧急情况。