Обязательно ли использовать атрибут фильтра для хранилища больших файлов Git (LFS) в gitattributes?

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

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


Дополнительная информация:
В результате исследований и тестирования я обнаружил, что атрибуты diff и merge на данный момент являются только заполнителями для 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

Кстати. также кажется, что не имеет значения, заключен ли шаблон в .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


person jowey    schedule 06.05.2020    source источник


Ответы (1)


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

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

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

Да. Кавычки нужны только в том случае, если в самом имени файла есть пробелы. Однако кавычки должны быть двойными кавычками< /a>, без одинарных кавычек: "*.png".

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


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

2Более подробно: когда вы проверили коммит H (какой-то хэш-идентификатор), Git, по сути, активен не один, а три копии каждого файла:

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

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

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

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

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

Обычно git add file работает путем копирования и сжатия данного файла во внутренний объект большого двоичного объекта, а затем записывает его в индекс. Однако если вы настроите для файла чистый фильтр, Git не будет читать файл напрямую: фильтр смазывания прочитает и редактирует файл. Фильтр пятен LFS редактирует файл, считывая данные и сохраняя их на сервере LFS, а затем генерируя новый ключ поиска.

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

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

person torek    schedule 06.05.2020
comment
Спасибо за ваше объяснение. Не могли бы вы уточнить, что вы подразумеваете под [...], если собираетесь использовать команду git front end [...]? Я думал, что через определение глобального фильтра в .gitconfig фильтр будет использоваться автоматически, если файл отслеживается через .gitattributes, но если я вас правильно понимаю, это будет только в том случае, если фильтр явно указан в файле (хотя связанный .gitattributes файл просто неисправен?) или если я использую альтернативную команду git? Как это будет выглядеть? - person jowey; 07.05.2020
comment
Вы можете использовать команду или псевдоним, который настраивает для вас файл атрибутов (например, .git/info/attributes) вместо (обычно фиксируемого) файла .gitattributes. Это также может предоставить -c опции, чтобы вам не нужно было определять драйверы. Я не знаю, есть ли какой-то интерфейс, который делает это. - person torek; 07.05.2020
comment
Еще раз спасибо за разъяснения. Я попытался найти ресурс, в котором говорится, что фильтры обязательны для LFS, но не могу найти. Не могли бы вы добавить один к своему ответу, прежде чем я приму его, пожалуйста. - person jowey; 08.05.2020
comment
Смотри новые сноски :-) - person torek; 08.05.2020
comment
Вау - спасибо за это масштабное обновление. Я вижу, что мое понимание того, для чего предназначен .gitattributes и как работает Git LFS, было совершенно неверным. Вы очень помогли мне разобраться в теме. - person jowey; 08.05.2020