Jeff King schrieb: > The "diff" gitattribute is somewhat overloaded right now. It > can say one of three things: > > 1. this file is definitely binary, or definitely not > (i.e., diff or !diff) > 2. this file should use an external diff engine (i.e., > diff=foo, diff.foo.command = custom-script) > 3. this file should use particular funcname patterns > (i.e., diff=foo, diff.foo.(x?)funcname = some-regex) > > Most of the time, there is no conflict between these uses, > since using one implies that the other is irrelevant (e.g., > an external diff engine will decide for itself whether the > file is binary). > > However, there is at least one conflicting situation: there > is no way to say "use the regular rules to determine whether > this file is binary, but if we do diff it textually, use > this funcname pattern." That is, currently setting diff=foo > indicates that the file is definitely text. I don't get your point. Can you provide an example? The reason why I'd like to understand the issue is because I like the diff.foo.textconv that you introduce in patch 4/4, but I dislike that I have to set diff.foo.binary to false in order to use the textconv. So, why is this .binary needed? > This patch introduces a "binary" config option for a diff > driver, so that one can explicitly set diff.foo.binary. We > default this value to "don't know". That is, setting a diff > attribute to "foo" and using "diff.foo.funcname" will have > no effect on the binaryness of a file. To get the current > behavior, one can set diff.foo.binary to true. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
