5

We've created a list of text and binary file types for our project repository, but i'm afraid that some types might have slipped out of that classification, or that in the future someone might add a new file type forgetting about adding it to the .gitattribute file.

What is the default behavior for file types that are not on this file under some of the categories? can be the default behavior for file types that are not mentioned set to 'binary'? i think its less problematic to have text files that are not really treated like text for purposes like autocrlf conversion, than to have it change line endings to a rar file just because its file type is not mentioned in the config

lurscher
  • 25,930
  • 29
  • 122
  • 185

1 Answers1

4

Default is to try to decide if a file is text or binary - if it is regarded as binary, do nothing, if text, treat it like core.eol and/or autocrlf settings have been defined. For most of the use cases, the detection of binary works. There are some where it doesn't, and .gitattributes can help there.

See also this question I asked earlier that is partly related.

EDIT: About defaulting most to binary, see this question. Basically it can be done, with something like this in .gitattributes:

* binary
*.txt crlf

So star should be the first rule.

Edit: changed order - at some point this has been documented to be that these go fro general to more specific, latter overriding former.

eis
  • 51,991
  • 13
  • 150
  • 199
  • 5
    The [manual](https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html) says *"When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute. The rules how the pattern matches paths are the same as in .gitignore files; see gitignore(5)"*. So it seems the star should be put first and then, you override with `*.txt text diff merge` to reput all attributes unset by `binary` which is an alias for `-text -diff -merge`. – Matt Sep 17 '13 at 13:10
  • Edited the answer to correct it, as per @Matt's comment. – trk Feb 28 '19 at 09:28