git lfs migrate --no-rewrite 报 unable to find entry，文件却在子目录

LightingData.asset 在项目中确实存在，执行 git lfs migrate import --no-rewrite LightingData.asset 却报 unable to find entry LightingData.asset in tree。换成 --include="LightingData.asset" 的历史迁移又能找到它。两种模式接收参数的方式不同：--no-rewrite 要求实际文件路径，不会拿一个文件名到所有子目录里搜索。

以下按 Git LFS 3.8.0 的无历史重写模式说明。不要因为另一条命令能成功匹配，就用会重写历史的迁移替代原目标。

从仓库根目录核对完整路径

先确认当前工作目录和准备迁移的分支：

git rev-parse --show-toplevel
git branch --show-current
git status --short

在根目录检查实际已跟踪路径，而不是只看文件浏览器中的 basename。比如目标是：

git ls-files --error-unmatch -- "Assets/Scenes/Demo/LightingData.asset"
git check-attr filter -- "Assets/Scenes/Demo/LightingData.asset"

路径是示例，应替换成索引中的准确名称，保留大小写和引号。第二条应确认这个文件已经匹配 LFS 属性。仅在磁盘上找到未跟踪文件，或者只配置了一个与实际路径不匹配的 .gitattributes 模式，不满足这里的前提。

无重写模式传入具体文件名

保存当前提交、配置及所有需要保留的未提交文件，确认工作区和暂存区没有混入其他改动后，才在仓库根目录迁移已经核对的文件：

git lfs migrate import --no-rewrite \
  -m "Track selected scene data with Git LFS" \
  "Assets/Scenes/Demo/LightingData.asset"

该模式会在当前分支创建新提交，把所选对象转成 LFS 指针，不改写已有提交。多个文件应分别传入完整路径；"*.asset" 不是它支持的递归匹配表达式。引号只能控制 shell 参数传递，不能让命令突然具备通配符搜索功能。

未加引号的星号若被 shell 展开，可能恰好传出一组有效路径，但展开范围取决于 shell 和目录结构。不能据此认定 Git LFS 自己支持 glob。也不要照搬 $(find ...) 拼参数：空格、换行、特殊文件名和参数长度都会改变结果。

无重写模式只操作当前分支，--include-ref 等基础迁移选项在这个子模式中被忽略。想让其他分支采用新的跟踪方式，应在审查新提交之后按正常流程合入，不是在同一条命令里追加基础模式的分支选项。

用 renormalize 时也要审暂存内容

另一条不重写历史的路径是，在正确的 LFS 属性已经建立后，用 Git 的 clean 流程重新暂存选定文件。Git 2.16 及以上支持 --renormalize；对一个明确路径，可以使用：

git add --renormalize -- "Assets/Scenes/Demo/LightingData.asset"
git diff --cached

这会修改暂存区，不自动创建提交。检查完整暂存差异，确认没有把原本不该提交的内容一起带入，再按项目流程提交。属性中的其他 clean 或换行规则也可能生效，不能把所有变化都当成 LFS 转换。

不要用 git rm --cached 配合 git add . 作为无条件修复。那会扩大索引变更范围，与只迁移几份已确认文件的目标不同。文件很多且包含特殊名称时，另用经过审查的路径列表方案，不临时用按空白分割的命令替代准确路径。

新提交不会清理旧历史

迁移后确认选定路径的提交对象已是预期 LFS 指针，工作区仍能读取真实内容，并通过原项目检查。正式分享前，还要确认 LFS 服务、对象上传与读取权限可用；本地生成迁移提交，不等于远端已经取得所有对象。

--no-rewrite 保留了旧提交，所以过去的大文件仍在 Git 历史中。它不能缩小既有历史或修复远端历史大小限制。需要清理历史时，那是另一次需要完整备份和协作计划的操作，不应作为这条路径报错的顺带处理。

迁移中若出现覆盖工作区修改的确认，停下来核对哪些文件变脏了，不要加 --yes 跳过。回退新提交也不会自动处理已经上传的对象；在验证完成前保留原始文件、迁移前引用和本地对象缓存。