Вывод, который вы показываете, указывает, что LFS настроен, как вы говорите, таким образом, чтобы он должен отслеживать файл, о котором идет речь.
Однако похоже, что эта конфигурация была настроена после того, как файл уже был добавлен в репозиторий, и поэтому этот конкретный файл не является под контролем LFS. LFS знает, что предполагается для управления файлом по этому пути, но видит исходный файл (а не указатель), на который фактически ссылаются в репо по этому пути, следовательно, Encountered 1 file(s) that should've been pointers, but weren't.
Скорее всего, сами команды git выполнили бы свои ожидаемые задачи [1], но вы также получите эти предупреждения, чтобы сообщить вам, что LFS не может выполнять свою работу, как сейчас.
Вы можете довольно легко исправить это "движение вперед".
git rm --cached Dependencies/BSI/Debug/64/TFC80NET.dll
git add Dependencies/BSI/Debug/64/TFC80NET.dll
Это приведет к повторной подготовке файла, и, по мере его пересмотра, «чистый» фильтр LFS перетасует его в репозиторий LFS и заменит его в индексе файлом указателя.
Вы можете зафиксировать это изменение, и тогда операции с этой фиксации не получат вышеуказанные предупреждения, и никакие новые версии большого файла не будут зафиксированы непосредственно в репозитории ядра. (Это может или не может иметь значение, в зависимости от того, изменяется ли когда-либо этот .dll. Это минимальное минимальное значение, которое вы потенциально можете получить из LFS.)
Но то, что не сделает : он не удалит ни одну из существующих версий .dll из репозитория ядра. Это означает, что раздувание, которое уже есть, все еще будет там. Люди, клонирующие репо, будут по-прежнему обременены стоимостью загрузки этих версий, на которые имеются исторические ссылки.
Если вы хотите в полной мере воспользоваться LFS, это будет смысл переписать историю, будь то с помощью инструмента «lfs migrate», или режима lfs в BFG Repo Cleaner, или с помощью специального filter-branch сценария , У каждого из них есть свои проблемы и подводные камни, так что вы можете прочитать о том, что с ними связано.
Общим для всех таких методов является то, что они представляют собой переписывание истории, которое сделает недействительными все существующие клоны репо (а также любые инструменты или документацию, которые могут зависеть от конкретных значений идентификатора фиксации). Поэтому необходимо согласовать со всеми, кто использует репо, прежде чем делать такую переписывание. (Разумная практика состоит в том, чтобы каждый подталкивал все изменения к источнику - даже если они не находятся в полностью объединенном состоянии; затем каждый должен отказаться от своих локальных клонов; затем выполнить переписывание; а затем каждый должен повторно клонировать из вновь созданного убрал репо.)
[1] Если вы покопаетесь глубже и обнаружите, что команды сброса и извлечения не вернули файл в индексе и в рабочем дереве, тогда могут возникнуть дополнительные проблемы для решения.