是否必须在 gitattributes 中为 Git 大文件存储 (LFS) 使用过滤器属性？
Is it mandatory to use the filter attribute for Git Large File Storage (LFS) in gitattributes?
当我使用具有以下模式 *.png binary 的 .gitattributes 文件来处理带有 Git LFS 的大型 PNG 文件时，什么都没有发生，LFS 被忽略。
当我使用 git lfs track '*.png' 手动设置轨道模式时，我在 .gitattributes 文件中得到以下行：
'*.png' filter=lfs diff=lfs merge=lfs -text
这工作正常。
最近更新的 Git 或 Git LFS 是否有更改，强制使用过滤器属性？
或者模式是错误的？我猜这仍然很好，因为突出的资源 like this repository use it.
附加信息：
通过研究和测试，我发现 diff 和 merge 属性目前只是 LFS 的占位符，如果我删除它们也没有什么区别，但是删除 filter 属性再次破坏 LFS（没有错误 - 文件只是添加到存储库，就好像没有文件类型的模式一样）。
这对我来说没有意义，因为过滤器是在 运行 git lfs install 之后通过全局 GIT 配置强制执行的（如果我理解正确的话）。这里的相关部分来自 .gitconfig:
[filter "lfs"]
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
required = true
顺便说一句。 .git属性中的模式是否被引用（'*.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 的存储库
... was there a change in a recent update of Git or Git LFS that makes it mandatory to use the filter attribute?
否：它总是是强制性的。1原因是Git-LFS的工作方式是它使用涂抹和清洁过滤器 Git 存储，作为 存储库 中的内容，一个包含有关如何检索 另一个信息的文件 文件，根本没有存储在 Git 中。这个其他文件存储在某个服务器上——这不必与您的 Git 服务器相同——并由 smudge 过滤器从那里检索。 clean 过滤器将存储在另一台服务器上的文件更新（扩充）为新文件。2
Btw. it also seems it doesn't matter if the pattern in the .gitattributes is quoted ('*.png' filter=lfs -text) or not (*.png filter=lfs -text), is this correct?
是的。如果文件名本身包含 white-space ，则只需要引号。但是，the quotes must be double quotes，不是单引号："*.png".
（请注意，Git 对污迹和清洁过滤器的处理有点奇怪：驱动程序 定义在 .gitconfig 或 .git/config 文件，因此可以是全局的或每个存储库，但 驱动程序 的使用进入 .gitattributes，因此始终是每个存储库。这样做的原因与过滤器驱动程序的安全模型有关。）
1有人可以而且也许已经构建了一个前端命令来对您隐藏这一点，但如上所述仍然是必需的。
2更详细：当您提交 H（一些哈希 ID）检出时，Git 有，实际上，不是一个，而是每个文件的 三个 个“活动”副本：
这些副本中的一个被永久冻结，并且在当前提交中，即提交 H。这个副本——或者它的内容，无论如何；模式和文件名分开存储——采用特殊的、只读的、Git-only 格式，并针对可能在其他 Git 提交中的相同副本进行重复数据删除。
Git 调用这些冻结格式的内容对象 blob 对象。你通常不会直接与他们打交道。
第二个副本是另一个去重的 blob 对象——冻结格式的内容——但是因为它存储在 Git 的 index , 可以随时更换。
文件的最后一个副本在您的工作树中，是一个普通的日常文件。它没有被压缩，也不是只有 Git 可以读取而没有人可以写入的特殊格式：它是一个普通的日常文件。
通常，最后一个文件是通过复制和解压缩内部 blob 对象生成的。但是，如果你为一个文件设置了一个 污点过滤器 ，而不是 Git 只是自己解压，Git 解压文件然后 运行s 通过污迹过滤器的内容。 LFS 污迹过滤器读取内容，然后调用 LFS 服务器并说“这是查找键：给我 real 内容”。 LFS 涂抹过滤器将检索到的文件写入您的工作树。
通常，git add <em>file</em> 通过将给定文件复制并压缩到内部 blob 对象中来工作，并且然后将其写入索引。但是，如果您为文件设置了 clean 过滤器，Git 不会直接读取文件：它有 smudge 过滤器读取和 edit 文件。 LFS 涂抹过滤器通过读取数据并将其存储在 LFS 服务器上来“编辑”文件，然后生成新的查找键。
因此，当您安装了 LFS 过滤器时，Git 看到的唯一数据是 LFS-server-lookup 键。
在 .gitattributes and/or .git/info/attributes 中设置了对哪些文件使用何种污迹和清洁过滤器的选择。使用 git config 或 git config --global 或 Git 配置文件中设置了给定污迹或清洁过滤器的 到 运行 的程序或git config --system 例如。
当我使用具有以下模式 *.png binary 的 .gitattributes 文件来处理带有 Git LFS 的大型 PNG 文件时，什么都没有发生，LFS 被忽略。
当我使用 git lfs track '*.png' 手动设置轨道模式时，我在 .gitattributes 文件中得到以下行：
'*.png' filter=lfs diff=lfs merge=lfs -text
这工作正常。
最近更新的 Git 或 Git LFS 是否有更改，强制使用过滤器属性？
或者模式是错误的？我猜这仍然很好，因为突出的资源 like this repository use it.
附加信息：
通过研究和测试，我发现 diff 和 merge 属性目前只是 LFS 的占位符，如果我删除它们也没有什么区别，但是删除 filter 属性再次破坏 LFS（没有错误 - 文件只是添加到存储库，就好像没有文件类型的模式一样）。
这对我来说没有意义，因为过滤器是在 运行 git lfs install 之后通过全局 GIT 配置强制执行的（如果我理解正确的话）。这里的相关部分来自 .gitconfig:
[filter "lfs"]
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
required = true
顺便说一句。 .git属性中的模式是否被引用（'*.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 的存储库
... was there a change in a recent update of Git or Git LFS that makes it mandatory to use the filter attribute?
否：它总是是强制性的。1原因是Git-LFS的工作方式是它使用涂抹和清洁过滤器 Git 存储，作为 存储库 中的内容，一个包含有关如何检索 另一个信息的文件 文件，根本没有存储在 Git 中。这个其他文件存储在某个服务器上——这不必与您的 Git 服务器相同——并由 smudge 过滤器从那里检索。 clean 过滤器将存储在另一台服务器上的文件更新（扩充）为新文件。2
Btw. it also seems it doesn't matter if the pattern in the .gitattributes is quoted (
'*.png' filter=lfs -text) or not (*.png filter=lfs -text), is this correct?
是的。如果文件名本身包含 white-space ，则只需要引号。但是，the quotes must be double quotes，不是单引号："*.png".
（请注意，Git 对污迹和清洁过滤器的处理有点奇怪：驱动程序 定义在 .gitconfig 或 .git/config 文件，因此可以是全局的或每个存储库，但 驱动程序 的使用进入 .gitattributes，因此始终是每个存储库。这样做的原因与过滤器驱动程序的安全模型有关。）
1有人可以而且也许已经构建了一个前端命令来对您隐藏这一点，但如上所述仍然是必需的。
2更详细：当您提交 H（一些哈希 ID）检出时，Git 有，实际上，不是一个，而是每个文件的 三个 个“活动”副本：
这些副本中的一个被永久冻结，并且在当前提交中，即提交 H。这个副本——或者它的内容，无论如何；模式和文件名分开存储——采用特殊的、只读的、Git-only 格式，并针对可能在其他 Git 提交中的相同副本进行重复数据删除。
Git 调用这些冻结格式的内容对象 blob 对象。你通常不会直接与他们打交道。
第二个副本是另一个去重的 blob 对象——冻结格式的内容——但是因为它存储在 Git 的 index , 可以随时更换。
文件的最后一个副本在您的工作树中，是一个普通的日常文件。它没有被压缩，也不是只有 Git 可以读取而没有人可以写入的特殊格式：它是一个普通的日常文件。
通常，最后一个文件是通过复制和解压缩内部 blob 对象生成的。但是，如果你为一个文件设置了一个 污点过滤器 ，而不是 Git 只是自己解压，Git 解压文件然后 运行s 通过污迹过滤器的内容。 LFS 污迹过滤器读取内容，然后调用 LFS 服务器并说“这是查找键：给我 real 内容”。 LFS 涂抹过滤器将检索到的文件写入您的工作树。
通常，git add <em>file</em> 通过将给定文件复制并压缩到内部 blob 对象中来工作，并且然后将其写入索引。但是，如果您为文件设置了 clean 过滤器，Git 不会直接读取文件：它有 smudge 过滤器读取和 edit 文件。 LFS 涂抹过滤器通过读取数据并将其存储在 LFS 服务器上来“编辑”文件，然后生成新的查找键。
因此，当您安装了 LFS 过滤器时，Git 看到的唯一数据是 LFS-server-lookup 键。
在 .gitattributes and/or .git/info/attributes 中设置了对哪些文件使用何种污迹和清洁过滤器的选择。使用 git config 或 git config --global 或 Git 配置文件中设置了给定污迹或清洁过滤器的 到 运行 的程序或git config --system 例如。