git clean过滤器显示git diff结果的差异 [英] git clean filter shows differences in the result of git diff

问题描述

我设置了一个干净的过滤器，以对uncrustify应用自动格式化.相应的污迹过滤器不执行任何操作，仅调用cat.

I setup a clean filter to apply autoformat with uncrustify. The corresponding smudge filter does nothing, it just calls cat.

[filter "autoformat"]
        clean = uncrustify -c ~/tmp/autoformat/uncrustify.cfg --replace
        smudge = cat

我的问题是当我结帐时master，git表示我的工作树与提交不同，并且所显示的区别是干净过滤器的作用.

My problem is that when I checkout e.g. master, git says my working tree differs from the commit, and the difference that shows is what the clean filter does.

似乎在diff之前应用了干净的过滤器.那是对的吗?是否可以禁用此功能?会是个好主意吗?

It seems that the clean filter is applied before diff. Is that correct? Is it possible to disable this? Would it be a good idea?

我想要一个将自动套用格式应用于暂存区的解决方案，即仅已暂存的块.清洁过滤器不是合适的解决方案吗?

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?

对于在unrustify配置中不符合我的编码标准的主提交，checkout -f HEAD^后跟checkout master -f表示差异.这既令人困惑又麻烦(git拒绝签出其他内容，以防止丢失更改).

With a master commit that does not conform to my coding standard in my uncrustify config, checkout -f HEAD^ followed by checkout master -f shows a diff. This is both confusing and cumbersome (git refuses to checkout something else, to prevent losing changes).

推荐答案

似乎在diff之前应用了干净的过滤器.正确吗?

It seems that the clean filter is applied before diff. Is that correct?

是的.至少在某些情况下必须.例如，考虑如果污迹过滤器由每个字符加倍"组成，而干净过滤器由删除加倍"组成，或者如果污迹过滤器由翻译成"组成，如果看起来太奇怪了，会发生什么情况?一些备用字符集"，然后干净的过滤器会转换回去.

Yes. In at least some cases it must be. Consider, for instance, what happens if the smudge filter consists of, say, "double every character" and the clean filter consists of "remove the doubling"—or, if that seems too peculiar, if the smudge filter consists of "translate into some alternate character set" and the clean filter translates back.

用于比较工作树与实际提交的git diff 必须或者对提交的内容运行 smudge 过滤器，或者运行 clean 过滤工作树的内容.或者它甚至可以同时运行，并且输出将进入临时文件. (我很确定我很久以前对此进行了测试，发现Git使用的方法是运行干净的过滤器，而不是污迹过滤器.但是请参阅

A git diff to compare the work-tree against an actual commit must either run the smudge filter on the commit's content, or run the clean filter on the work-tree's content. Or it might even run both, with the output going to temporary files. (I'm pretty sure I tested this once, long ago, and found that the approach Git used was to run the clean filter, rather than the smudge filter. But see Cyker's comment, which suggests it runs both filters and then diffs smudged results.)

是否可以禁用此功能?会是个好主意吗?

Is it possible to disable this? Would it be a good idea?

参见上文-充其量您可能会有一个仅运行污迹过滤器"选项(但没有一个).

See above—at best you might have a "run only the smudge filter" option (but there is none).

请注意，根据定义，索引中的内容已经干净.清理发生在从工作树到索引的过渡中；从索引到工作树的过渡中会发生伪装.

Note that what's in the index is already clean, by definition. Cleaning happens on the transition from work-tree to index; smudging happen on the transition from index to work-tree.

现有的提交严格是只读的，并且将提交提取到索引中不会进行任何更改.因此，尽管索引内容按定义是干净的，但如果干净的过滤器本身发生了变化，则它们可能与通过重新运行过滤器所得到的不匹配.

Existing commits are strictly read-only and extracting a commit into the index makes no changes. Hence, while the index contents are clean by definition, if the clean filter itself has changed, they may not match what you would get by re-running the filter.

我想要一个将自动套用格式应用于暂存区的解决方案，即仅已暂存的块.清洁过滤器不是合适的解决方案吗?

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?

这与您的思维方式不符.

This does not work the way you are thinking.

运行git add不会对索引副本应用diff块:运行git add会将 entire 工作树文件复制到索引中.整个东西都被清理了.

Running git add does not apply diff hunks to the index copy: running git add copies the entire work-tree file into the index. The whole thing gets cleaned.

运行git add -p也不实际将diff块应用于索引副本，因为从字面上讲，它不能.取而代之的是，git add -p将索引副本提取到临时文件中，将diff大块应用于临时文件，然后将 entire 临时文件(具有大块应用)复制到索引中，并通过清洁过滤器.整个事情再次被清理了，只是整个事情"是通过修补污损的索引副本而构建的临时文件.

Running git add -p also does not actually apply diff hunks to the index copy, because it literally can't. Instead, git add -p extracts the index copy to a temporary file, applies a diff hunk to the temporary file, and then copies the entire temporary file (with applied hunk) into the index, running that through the clean filter. Once again the whole thing gets cleaned—it's just that "the whole thing" is a temporary file built by patching the smudged index copy.

换句话说，每个文件的索引副本本身就是一个实体，独立于HEAD提交副本和工作树副本. Git在git checkout时间启动，只需将文件的提交副本直接复制到索引中(无更改，没有过滤器)，然后将文件的索引副本复制到工作树中(涂抹过滤器). git add时，Git在工作树文件(或修补的结果)上运行clean过滤器，并将其填充到索引中. ¹

In other words, the index copy of each file is an entity unto itself, independent of the HEAD commit copy and the work-tree copy. Git starts out, at git checkout time, by just copying the commit copy of the file directly into the index (no changes, no filters), then copies the index copy of the file into the work-tree (smudge filter). At git add time, Git runs the clean filter on the work-tree file (or the patched result) and stuffs that into the index.¹

¹ 从技术上讲，索引不是保存文件本身，而是保存它们的内容哈希值.添加文件包括将文件写入存储库！生成的 blob 对象的哈希ID进入索引.索引条目可防止对blob进行垃圾收集，如果索引是使用blob的唯一位置(如果blob与某个已提交的blob匹配，则可以从Grim Collector中安全使用).

¹Technically, the index holds not the files themselves, but rather their content hashes. Adding a file consists of writing the file into the repository! The hash ID of the resulting blob object goes into the index. The index entry keeps the blob from being garbage-collected, if the index is the only place the blob is used (if the blob matches some committed blob then it's safe from the Grim Collector).

这篇关于git clean过滤器显示git diff结果的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！