添加丢失的 LFS 文件会导致：遇到本应是指针的 X 文件，但事实并非如此

Question

我有一个 git 存储库，其中包含现有文件。然后我设置 git-lfs 来处理特定类型的文件（例如 pdf、tif 等）。这对于新文件来说效果很好，并且它们按预期存储在 LFS 中。但是，本来应该存储在 LFS 中的文件却没有存储在存储库中。这会导致克隆存储库时出现以下错误：

Encountered 361 file(s) that should have been pointers, but weren't:

如何转换这些文件以便将它们存储在 LFS 而不是 git 中？我不在乎重写历史，只需要整理一下以继续前进。

Answer 1

我是如何解决的：

git lfs migrate import --no-rewrite path

参见：https://tech-notes.maxmasnick.com/fixing-files-that-should-have-been-pointers-in-lfs-but-werent

Answer 2

我是如何解决的：

• 创建了一个新分支
• 复制了所有文件
• 删除了列出的应该是指针的内容。进行了此更改
• 复制文件以重新添加它们
• 将新文件提交到 git（然后将它们添加到 LFS 而不是 git 存储库中）
• 推送更改

Answer 3

对于有很多路径来解决此问题的问题，在 derekhh 的答案下建议使用

git lfs migrate import --no-rewrite **/*

；然而，即使每个人都在他们的 shell 中扩展了通配符支持，一旦到达 Git 中与 .gitattributes 文件中的 lfs 模式不匹配的文件，这种情况很快就会失败。

这里有两种对我有用的方法：

方式1

• 假设我知道所有问题路径都属于的一些模式（即它们都是 jpeg）

git lfs migrate import --no-rewrite $(find . -type f -iname '*.jpg')

方式2

• 如果我不关心是否（或实际上想要）为每个固定文件单独的新提交
• 再次假设我提前知道路径模式

find . -type f -iname '*.jpg' | while read jpg; do
  git lfs migrate import --no-rewrite "$jpg"
done

编辑1：关于

find

的旁注

上面我使用 bash

find

命令列出文件，但我也可以使用

git ls-files -- '*.jpg'

达到相同的效果。 （注意：不区分大小写的路径规范将是

':(icase)*.jpg'

。）

您可能有兴趣知道

git ls-files

通常比

find

命令更快 — 在某些操作系统/文件系统 (Windows NTFS 👀) 上明显更快 — 如果您正在处理大量数据，这可能是可取的文件。当然，有一个一般性的警告，

git ls-files

（默认情况下）仅列出当前 Git 存储库跟踪的文件，但在本文的上下文中，这实际上可能是一件好事！ IE。它将防止子模块中的匹配文件混合到 LFS 中；

find

无法区分。

编辑2

更多注释，但

git ls-files

仅列出当前索引上的文件。这些天我更喜欢

git ls-tree -r --name-only $REV

，其中 REV 是分支/标签/提交引用。它更长，但更接近我吉米操纵 ls 文件的样子。

出于某种原因，

git ls-files

仍然有效，并且如果你传递一个提交式的参数，它不会警告你，这误导了我，直到我注意到并确认它确实是一个被忽略的参数。