Re: Is the "text" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?

[Jeff King <peff@peff.net>]

On Fri, Mar 30, 2012 at 10:49:42AM -0700, Chris Harris wrote:

> > However, I find the behavior of "Git Extensions" to be questionable. I
> > can see the rationale for thinking that "-text" means more than just
> > handling line-endings, but I think "-diff" is probably a better choice
> > for seeing if something is binary (or even checking the "binary" macro).
> > Those are what git uses itself.
> [...]
> A related point of confusion: I've noticed that, if you start with a
> question along the lines of "how can I explicitly tell git that a file
> is binary", then the web currently gives a slightly confusing array of
> answers. For example:
> * The Pro Git Book (http://progit.org/book/ch7-2.html) tells you to
> use either "binary" or "-crlf -diff"

I think setting "binary" is the most sane thing. Ultimately, I think
what it comes down to is this: git provides a bunch of per-operation
attributes for treating a file as binary for a particular operation. It
also provides a "binary" macro to conveniently cover all of the
operations.

Git Extensions cares about binary-ness for a _new_ operation, which is
showing the file at all (that is what I got from your original email, at
least; I have never used Git Extensions myself). The equivalent in git
would be perhaps for "git show HEAD:file" to either print a text file,
or to say "This is a binary file". But since git itself does not care
about binary-ness for that operation (we just always show the file), we
have not defined an operation-specific attribute.

So what is something like Git Extensions to do? It can introduce a new
attribute, but of course nobody is likely to be using it. It can depend
on "binary", except that some people will manually spell out "-crlf
-diff" instead of saying "binary". Or it can piggy-back on "-text" or
"-diff", which can be subtly wrong in cases where the file is not
binary, but you want to disable those operations (i.e., your case).

Of those, just checking "binary" seems like the least wrong thing to me.

> * "man gitattributes" has helpful info, but it's scattered across
> different sections. In the section "Marking files as binary", it says
> "The simplest way to mark a file as binary is to unset the diff
> attribute in the .gitattributes file".

Note that "Marking files as binary" is actually a subsection in
"Generating diff text". We could probably do a better job of mentioning
the "binary" macro there, though.

> (Note: This implies that there > are other ways you might also want to
> consider.)

Yes. You can also use a custom diff driver (e.g., "diff=foo"), and then
tell the diff driver that the file should be considered binary (by
setting diff.foo.binary in your config).

> Under "Performing a three-way merge" you also learn that "-merge" is
> "suitable for binary files that do not have a well-defined merge
> semantics".

Arguably the "binary" macro should imply "-merge". And like -diff, we
the documentation should probably reference the section on the "binary"
macro.

> You learn about the "binary" attribute only under the section
> "Defining Macro Attributes", which says that it means "-text -diff",
> but not in what cases you might want to use it. The section describing
> "text"/"-text" does not contain the word "binary" at all, so you have
> to infer whether it's a helpful setting for binary files.

I think it is the case that binary files should imply "-text", but
"-text" does not necessarily imply binary files. But like the other
spots, it should probably say "hey, if you are dealing with a binary
file, you might want to just set the binary attribute macro".

-Peff