Consider removing "*.thing text" from lots of .gitattributes files? about gitattributes HOT 2 OPEN

This also relates to this confusing blurb from the readme:

I can understand why this could be a thing that is done... but I don't think this is a wise thing to recommend for all projects. Most projects are a-OK with the defaults that Git gives. Even the Linux kernel, a premier example of a large Git project, uses a very basic .gitattributes file: https://github.com/torvalds/linux/blob/master/.gitattributes 😆

from gitattributes.

Sorry for the delay, I wanted to do a bit of research on the subject.

I think the primary concern would be with leaving the entry unspecified, as gitattributes would frequently be used to solve the line ending problem in a per-repository level [1]. Leaving an entry unspecified means files might end up with different line endings depending on the OS of the machine that the commit is happening, also mixing them can cause issues. Project owners who want to enforce consistent line endings (which may differ per file type) would prefer specifying attributes.

* text=auto along with more specific entries can be used to cut-down on entry count - then, text is auto instead of unspecified for entries that are not explicit listed. Note that there is a possibility of failure: misdetection, encoding issues, ambiguity (e.g. with mixed_files). Therefore, the explicit entries can avoid potential issues. I am not sure of the rarity of this, but given that gitattributes files are typically "install-and-forget" and don't change very often, having the additional verbosity for less chance of encountering issues seems worthwhile.

Furthermore, in the entries you referenced, there are also additional properties, like diff=fortran that would need the corresponding elements to have their own entries.

In this post, you reference: *.txt text=auto (to clarify: as opposed to *.txt text). Is that intentional? I am not sure if there is a benefit to the former and we could remove them as redundant, but quick grep shows that we don't have such entries in the current collection (there are some catch-all * text=auto though).

Related:

1. https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
2. https://www.git-scm.com/docs/gitattributes
3. https://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat
4. https://stackoverflow.com/questions/48789703/gitattributes-using-text-auto-with-filters

from gitattributes.