git clean filter 在 git diff 的结果中显示差异
git clean filter shows differences in the result of git diff
我设置了一个干净的过滤器来应用带有 uncrustify 的自动套用格式。相应的污迹过滤器什么也不做，它只是调用 cat.
[filter "autoformat"]
clean = uncrustify -c ~/tmp/autoformat/uncrustify.cfg --replace
smudge = cat
我的问题是当我结帐时，例如master、git 说我的工作树与提交不同，显示的区别是 clean 过滤器的作用。
似乎在 diff 之前应用了 clean 过滤器。那是对的吗？是否可以禁用此功能？这是个好主意吗？
我想要一个将自动格式应用于暂存区的解决方案，即仅暂存的帅哥。清洁过滤器不是合适的解决方案吗？
在我的 uncrustify 配置中，主提交不符合我的编码标准，checkout -f HEAD^ 后跟 checkout master -f 显示差异。这既令人困惑又麻烦（git 拒绝签出其他内容，以防止丢失更改）。
It seems that the clean filter is applied before diff. Is that correct?
是的。至少在某些情况下，它 必须 是。例如，考虑一下，如果污迹过滤器由 "double every character" 组成，而清洁过滤器由 "remove the doubling" 组成——或者，如果这看起来太奇怪，如果污迹过滤器由 [=73] 组成=] 干净的过滤器翻译回来。
A git diff 将 work-tree 与实际提交进行比较 must 运行 smudge 过滤提交的内容，或 运行 clean 过滤 work-tree 的内容。或者它甚至可能 运行 两者，输出到临时文件。 （我很确定很久以前我测试过一次，发现 Git 使用的方法是 运行 清洁过滤器，而不是污迹过滤器。但是请参阅 ，这表明它 运行 既过滤又区分模糊的结果。）
Is it possible to disable this? Would it be a good idea?
见上文 - 最多你可能有一个 "run only the smudge filter" 选项（但有 none）。
请注意，根据定义，index 中的内容已经干净了。清理发生在从 work-tree 到索引的过渡过程中；从索引到 work-tree.
的过渡发生污迹
现有提交严格 read-only 并且将提交提取到索引中不会发生任何更改。因此，虽然索引内容根据定义是干净的，但如果干净过滤器本身已更改，它们可能与您通过 re-running 过滤器获得的内容不匹配。
I would like a solution where autoformat is applied to the staging area, that is only the hunks that were staged. Isn't clean filter an appropriate solution?
这和你想的不一样。
运行 git add 不将 diff hunks 应用于索引副本：运行ning git add 复制 entire work-tree 文件进入索引。整个东西都被清理干净了。
运行 git add -p 实际上也没有将 diff hunks 应用于索引副本，因为它实际上不能。相反，git add -p 将索引副本提取到临时文件，将 diff hunk 应用于临时文件，然后将 整个 临时文件（已应用 hunk）复制到索引中, 运行ning 通过干净的过滤器。整个事情又一次得到了清理——只是 "the whole thing" 是一个通过修补弄脏的索引副本构建的临时文件。
换句话说，每个文件的索引副本本身就是一个实体，独立于 HEAD 提交副本和 work-tree 副本。 Git 开始，在 git checkout 时间，通过将文件的提交副本直接复制到索引中（没有更改，没有过滤器），然后将文件的索引副本复制到 work-tree（涂抹滤镜）。在 git add 时，Git 运行 对 work-tree 文件（或修补后的结果）进行清理过滤器并将其填充到索引中。1
1从技术上讲，索引保存的不是 文件本身， 而是它们的 内容哈希值 .添加文件包括将文件写入存储库！生成的 blob 对象的哈希 ID 进入索引。如果索引是唯一使用 blob 的地方（如果 blob 与某个已提交的 blob 匹配，那么它在 Grim 收集器中是安全的）。
我设置了一个干净的过滤器来应用带有 uncrustify 的自动套用格式。相应的污迹过滤器什么也不做，它只是调用 cat.
[filter "autoformat"]
clean = uncrustify -c ~/tmp/autoformat/uncrustify.cfg --replace
smudge = cat
我的问题是当我结帐时，例如master、git 说我的工作树与提交不同，显示的区别是 clean 过滤器的作用。
似乎在 diff 之前应用了 clean 过滤器。那是对的吗？是否可以禁用此功能？这是个好主意吗？
我想要一个将自动格式应用于暂存区的解决方案，即仅暂存的帅哥。清洁过滤器不是合适的解决方案吗？
在我的 uncrustify 配置中，主提交不符合我的编码标准，checkout -f HEAD^ 后跟 checkout master -f 显示差异。这既令人困惑又麻烦（git 拒绝签出其他内容，以防止丢失更改）。
It seems that the clean filter is applied before diff. Is that correct?
是的。至少在某些情况下，它 必须 是。例如，考虑一下，如果污迹过滤器由 "double every character" 组成，而清洁过滤器由 "remove the doubling" 组成——或者，如果这看起来太奇怪，如果污迹过滤器由 [=73] 组成=] 干净的过滤器翻译回来。
A git diff 将 work-tree 与实际提交进行比较 must 运行 smudge 过滤提交的内容，或 运行 clean 过滤 work-tree 的内容。或者它甚至可能 运行 两者，输出到临时文件。 （我很确定很久以前我测试过一次，发现 Git 使用的方法是 运行 清洁过滤器，而不是污迹过滤器。但是请参阅
Is it possible to disable this? Would it be a good idea?
见上文 - 最多你可能有一个 "run only the smudge filter" 选项（但有 none）。
请注意，根据定义，index 中的内容已经干净了。清理发生在从 work-tree 到索引的过渡过程中；从索引到 work-tree.
的过渡发生污迹现有提交严格 read-only 并且将提交提取到索引中不会发生任何更改。因此，虽然索引内容根据定义是干净的，但如果干净过滤器本身已更改，它们可能与您通过 re-running 过滤器获得的内容不匹配。
I would like a solution where autoformat is applied to the staging area, that is only the hunks that were staged. Isn't clean filter an appropriate solution?
这和你想的不一样。
运行 git add 不将 diff hunks 应用于索引副本：运行ning git add 复制 entire work-tree 文件进入索引。整个东西都被清理干净了。
运行 git add -p 实际上也没有将 diff hunks 应用于索引副本，因为它实际上不能。相反，git add -p 将索引副本提取到临时文件，将 diff hunk 应用于临时文件，然后将 整个 临时文件（已应用 hunk）复制到索引中, 运行ning 通过干净的过滤器。整个事情又一次得到了清理——只是 "the whole thing" 是一个通过修补弄脏的索引副本构建的临时文件。
换句话说，每个文件的索引副本本身就是一个实体，独立于 HEAD 提交副本和 work-tree 副本。 Git 开始，在 git checkout 时间，通过将文件的提交副本直接复制到索引中（没有更改，没有过滤器），然后将文件的索引副本复制到 work-tree（涂抹滤镜）。在 git add 时，Git 运行 对 work-tree 文件（或修补后的结果）进行清理过滤器并将其填充到索引中。1
1从技术上讲，索引保存的不是 文件本身， 而是它们的 内容哈希值 .添加文件包括将文件写入存储库！生成的 blob 对象的哈希 ID 进入索引。如果索引是唯一使用 blob 的地方（如果 blob 与某个已提交的 blob 匹配，那么它在 Grim 收集器中是安全的）。