*.chm binary
*.chm -diff
我曾尝试使用
*.chm
二进制文件,但我担心它仍然会尝试合并这些文件。 是否使用 -diff
更适合我想要做的事情?此设置是否适用于已提交给定类型的文件后?
谢谢。
*.chm binary
*.chm -diff
*.chm
二进制文件,但我担心它仍然会尝试合并这些文件。 是否使用 -diff
更适合我想要做的事情?[attr]binary -diff -merge -text
-diff
来覆盖 binary
可能更合适:实际上并没有太大的区别。 两者通常都可以使用,gitattributes文档将-diff
称为标记文件为二进制文件的最简单方法之一。 那么为什么不对.chm
文件使用它呢?.gitattributes file
[1] | [2] | [3]
------------------------|-----------------------|------------------------
*.chm binary | *.chm -diff | *.chm binary
*.chm -diff | |
$ git check-attr -a help.chm
------------------------|-----------------------|------------------------
help.chm: binary: set | help.chm: diff: unset | help.chm: binary: set
help.chm: diff: unset | | help.chm: diff: unset
help.chm: merge: unset | | help.chm: merge: unset
help.chm: text: unset | | help.chm: text: unset
注意: 上面的
[1]
与单行*.chm -diff binary
或*.chm binary -diff
在输出方面是相同的。这强烈暗示所有这些都逻辑上等同于只是*.chm binary
,并且不同于*.chm -diff
。
对于问题,是否使用-diff
更合适取决于你配置中的其他gitattributes以及你认为哪些属性适合或不适合。由于你没有在问题中共享它们,因此我可以考虑它们未定义以回答问题(这里没有冒犯,属性可以设置、取消或未定义)。但是,那样答案就不完整了。所以任何事情都是可能的,使用binary宏属性可能会取消或定义先前已经在存储库配置中生效的merge和/或text属性。
因此,对于我来说,binary
看起来比-diff
更可取,仅用于压缩答案(不太可能好),因为你关心合并二进制文件,而binary
宏属性则取消了以下后果的merge
属性:
取消设置
将当前分支的版本作为暂定合并结果,并声明合并存在冲突。这适用于没有明确定义的二进制文件合并语义。
(参考:merge
- 执行三方合并 - Gitattributes)
这与使用binary内置合并驱动程序相同。因此,就像binary宏属性建议的那样,您明确标记合并为“binary”。
与隐式标记文件为二进制的-diff
不同,binary宏属性确实更改了merge属性,因此取消设置diff属性允许使用不同于未设置merge属性合并驱动程序(这就是现有答案正确的地方,使用binary
与-diff
不同-它未列出宏的所有属性,错过了取消设置merge属性-它可能未记录在使用中的版本中,请确认git版本 < 1.7.12.4)。
-diff
应该就足够了,使用binary
可能不会有害,但会取消比通常需要更多的属性,因此在合并时更明确(没有提到text属性),但可能会产生意外的副作用和/或使将来的维护更加困难(尽管这相当理论化,但它可能会做得比你一开始担心的多一点)。-diff
,直到遇到实际问题。 最有可能的是,您已经解决了这个问题很久以前。$GIT_DIR/info/attributes
进行测试(它具有最高的优先级),因为它是本地克隆的,并且从未提交,然后使用git check-attr
验证它如何影响已提交文件的属性。.gitattributes
文件/文件夹中才会存储。