Обязательно ли использовать атрибут фильтра для Git Large File Storage (LFS) в gitattributes?

Question

Когда я использую файл .gitattributes со следующим шаблоном *.png binary для обработки больших файлов PNG с помощью Git LFS, ничего не происходит, LFS игнорируется.
Когда я устанавливаю шаблон дорожки вручную с помощью git lfs track '*.png' Я получаю следующую строку в файле .gitattributes :
'*.png' filter=lfs diff=lfs merge=lfs -text
Это работает нормально.

Так было ли изменение в недавнем обновлении Git или Git LFS, которое делает обязательным использование атрибута фильтра?
Или шаблон просто неверен? Я догадался, что это все еще в порядке, поскольку известные ресурсы , такие как этот репозиторий, используют его .

---

Дополнительная информация:
Благодаря исследованиям и тестированию я обнаружил, что diff и * Атрибуты 1023 * на данный момент являются только заполнителями для LFS, и это не имеет значения, если я их удалю, но удаление атрибута filter снова нарушает работу LFS (без ошибок - файлы просто добавляются в репозиторий, как если бы не было шаблона для типа файла).

Для меня это не имеет смысла, поскольку фильтр применяется через глобальную конфигурацию GIT после запуска git lfs install (если я правильно понимаю). Вот соответствующая часть из .gitconfig :

[filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true

Btw. также кажется, что не имеет значения, цитируется ли образец в .gitattributes ('*.png' filter=lfs -text) или нет (*.png filter=lfs -text), это правильно?

---

git -lfs / 2.10.0 (GitHub; windows amd64; go 1.12.7; git a526ba6b)
git версия 2.26.2

Протестировано в командной строке и с помощью Sourcetree.
Репозиторий из Bitbucket

Answer 1

... было ли изменение в недавнем обновлении Git или Git LFS, которое делает обязательным использование атрибута фильтра?

Нет: он имеет всегда был обязательным. ¹ Причина в том, что способ работы Git -LFS заключается в том, что он использует фильтры smudge и clean для сохранения Git, так как содержимое в ваш репозиторий , файл, содержащий информацию о том, как получить другой файл, который вообще не хранится в Git. Этот другой файл хранится на каком-то сервере - он не обязательно должен совпадать с вашими Git серверами - и извлекается оттуда фильтром smudge . Файл, хранящийся на этом другом сервере, обновляется (ну, дополняется) новым с помощью фильтра clean . ²

Btw. также кажется, что не имеет значения, указан ли шаблон в .gitattributes ('*.png' filter=lfs -text) или нет (*.png filter=lfs -text), это правильно?

Да . Вам нужны кавычки, только если в самом имени файла есть пробелы. Однако кавычки должны быть двойными кавычками , а не одинарными: "*.png".

(Обратите внимание, что Git обрабатывает пятна и чистые фильтры. немного странно: определение драйвера идет в файле .gitconfig или .git/config и, следовательно, может быть глобальным или для каждого репозитория, но использование драйвера входит .gitattributes и, следовательно, всегда для каждого репозитория. Причина этого связана с моделью безопасности вокруг драйверов фильтров.)

¹ Кто-то мог и, возможно, создал команду внешнего интерфейса, которая скрывает это от вас, но она по-прежнему требуется, как описано выше.

² В более подробно: когда у вас есть фиксация H (some ha sh ID), Git фактически имеет не одну, а три «активные» копии каждого файла :

• Одна из этих копий заморожена на все время и находится в текущей фиксации, то есть фиксации H . Эта копия - во всяком случае, ее содержание; режим и имя файла хранятся отдельно - в специальном формате, предназначенном только для чтения, только Git, и дедупликации для идентичных копий, которые могут быть в других Git коммитах.

  Git называет эти объекты содержимого замороженного формата объектами blob . Обычно вы не имеете дело с ними напрямую.

• Вторая копия - это еще один дедуплицированный объект blob - содержимое в замороженном формате, но потому что он хранится в Git index , его можно заменить в любой момент.

• Последняя копия файла находится в вашем рабочем дереве и является обычным повседневным файл. Он не сжат и не в каком-то специальном формате, который может читать только Git и никто не может писать: это обычный повседневный файл.

Обычно последний файл создается путем копирования -и-распаковка внутреннего объекта blob. Если вы настроили для файла фильтр размытия , вместо того, чтобы Git просто выполнять эту декомпрессию самостоятельно, Git распаковывает файл, но затем пропускает содержимое через фильтр размытия. Фильтр smudge LFS считывает содержимое, затем вызывает сервер LFS и говорит: «Вот ключ поиска: получите реальное содержимое». Фильтр размазывания LFS записывает полученный файл в ваше рабочее дерево.

Обычно git add <em>file</em> работает путем копирования и сжатия данного файла во внутренний объект blob, а затем записи его в индекс. Если вы настроили чистый фильтр для файла, Git не читает файл напрямую: он читает фильтр smudge и редактирует файл. Фильтр смазывания LFS «редактирует» файл, считывая данные и сохраняя их на сервере LFS, а затем генерируя новый ключ поиска.

Следовательно, когда у вас есть фильтры LFS, единственные данные Git - это ключ поиска LFS-сервера.

Выбор того, какие фильтры размытия и очистки для каких файлов использовать, устанавливается в .gitattributes и / или .git/info/attributes. Программа для запуска для данного пятна или чистого фильтра устанавливается в файле конфигурации Git, используя, например, git config, git config --global или git config --system.