git lfs 使用指针文件处理 repo 中的重复文件

Posted 2023-02-19

【中文标题】git lfs 使用指针文件处理 repo 中的重复文件

【英文标题】：git lfs handling of duplicated files in a repo using pointer files

【发布时间】：2022-01-15 04:35:41

【问题描述】：

我必须在不同目录的 repo 中复制由 git lfs 处理的文件（同名，相同内容）两次，以便我们的第 3 方软件正常工作。这是对我必须使用的第 3 方软件的限制。

./directory1/large_file.crg ./directory2/large_file.crg

git lfs 智能识别它们是同一个文件，并且只下载一次到本地 repo。其他文件只是获得指向真实文件位置的指针。这会导致第 3 方软件出现问题，因为它无法读取指针。

有什么方法可以强制 Git LFS 复制文件而不是指向它？ 或者有人可以指出我在哪里记录了这种行为，以便我向同事解释？

【问题讨论】：

要清楚一点，当您将这两个文件添加到 repo 时，完整文件存在两次，但是当您克隆回来时，您会得到一个指针？这对我来说听起来像是一个错误！克隆应该总是和原来的一样。

现在，您能否指定您的操作系统，以防特定于操作系统的行为？

出于好奇，Linux 是复制文件还是创建硬链接？ （在每个文件上运行ls -i 以查看inode。如果两个文件具有相同的inode，则它们是彼此的硬链接，即文件系统上只有一个文件，两个单独的目录条目指向它们。 ) Windows 不支持硬链接......当你说你得到一个“指针”时，你能更准确地了解什么样的指针？这是一种特定于 Windows 的软链接对象吗？

好的，那么我有一个新理论：您的原始存储库可能从一开始就从未包含该文件的两个副本。它是在 Linux 上创建的，大文件在一个目录中，而符号链接在另一个目录中。 Git 完全有能力存储符号链接。当您在 Linux 上检查它们时，它们运行良好。但是，当您在 Windows 上重新检查它们时，您会得到所看到的。

你不会喜欢这个解决方案：符号链接只是在操作系统之间不兼容，所以如果你有一个打算在 Linux 和 Windows 上使用的存储库，不要使用符号链接。所以我会做git rm <symlink version of the file>，复制大文件git add <copied version of the file>。 Git 足够聪明，可以为两者重用相同的 blob，但每个克隆中都有两个副本。

【参考方案1】：

TL;DR

不要在要在 Windows 和 Linux/Mac 上使用的存储库中使用符号链接。

符号链接的问题

根据问题下的 cmets，事实证明 repo 没有两个大文件副本，而是一个副本，以及一个指向它的 Linux 样式的符号链接。

Git 完全支持符号链接 - 您可以添加、修改、签入、签出。只要你留在 Linux 中，一切都会好起来的。

但是 Windows 不支持 Linux 风格的符号链接，所以你得到的东西是坏的，正如你在问题下的 cmets 中描述的那样。

解决方案：摆脱符号链接是跨平台的repos

这似乎不是一个好的解决方案，但如果您的 repo 旨在用于 Windows 和 *nix 操作系统，请避免使用符号链接。

您仍然会节省一些空间，至少在 Git 服务器上和 Git LFS 存储中也是如此，因为当一个 repo 中有两个相同的文件时，Git 足够聪明，可以重用同一个 blob。事实上，它不能做任何其他事情，因为 blob 的 sha1 哈希是用来存储和检索 blob 的！在使用该存储库的每个沙箱中，您将只有两个副本。