I've recently been reading up a bit on .gitattributes and also found places like this one, https://github.com/alexkaratarakis/gitattributes, where they try to maintain gitattributes for all file types. However in my mind, looking through those files, I instinctively think this is an unmaintainable mess. It means you'd have to update that file any time you use any new file extension, or any software brings out a new file extension, which is just impossible. When you're working with a team of 30 people it's just a nightmare to maintain some file like that, we can barely maintain a simple icons.svg file.
But along with that I have been coding and using git for many years, on many different projects, and I've never used .gitattributes. We use things like prettier on our project which rewrites newlines to "lf" and we have devs on windows and things like this never gives any issues, vscode also never gives any issues with things like this. Git also automatically picks up binary files like pngs and automatically shows text differences for files like svg, I've never had to configure that.
So I ask the question, is it really necessary to have this file? Because it seems to me like it's signing up for a ton of maintenance that's completely unnecessary and that git is smart enough to figure out what it should or shouldn't do with a file.
CodePudding user response：
is it really necessary to have this file?
Yes, for any setting (eol, diff, merge filters, content filters, ...) related to Git you want any collaborator to the repository to follow.
This differs from git config which, for security reason, remains local (both because it can include sensitive information, or dangerous directives)
A .gitattributes is part of your versioned source code, and contribute to establishing common Git standard.
For instance, I always put (as in VonC/gitcred/.gitattributes):
*.bat text eol=crlf
*.go text eol=lf
Because no matter how your IDE/editor is configured, I need CRLF for my Windows bat script to properly run, and I prefer LF for Go files, which I edit on Windows or Linux. I always considered local settings like core.autocrlf an anti-pattern, best left to false.
But a .gitattributes can declare many other Git elements:
working-tree-encoding, used for translation filesidentto embed file SHA1 as in herefilter, most notably used by Git LFS, as in here, and I used it many times before.diff, at least to avoid diffing binary files, or defining an external diff driver- hunk header (using
xfunnamefor instance): I mention them here. - merge filter like the
unityyamlmerge whitespaceto define whatdiffandapplyshould consider whitespace errors- ...
The .gitattributes file is not "mandatory", but certainly necessary as a useful tool in the Git toolbox, one that can be shared safely in a project code base.
CodePudding user response：
It depends. The most common uses for .gitattributes files are line ending handling, working-tree encodings, and Git LFS. If you're using Git LFS, then it's required for those files to be handled as LFS files.
Otherwise, if all you care about is line endings, it depends on your platform. If your project is Unix-only, then it's not required. However, if your project may be used across systems, it's typically helpful to have one to indicate which files are text (that is, should be subject to line ending conversion) and which are not. Git does often guess correctly, but it only looks at the beginning of the file, and in many cases, certain file types (notably PDFs) start with a large block of ASCII-compatible text and then include binary data, and Git will need help.
If you want to include things like shell scripts or batch files, you absolutely do need a .gitattributes file because POSIX shells don't accept CR as part of a line ending and batch files must contain CRLF. An eol=lf or eol=crlf is therefore required for reproducible behaviour.
Similarly, some people on Windows have tools that have not come into modern times (where we overwhelmingly use UTF-8) and still absolutely require their data to be in little-endian UTF-16 with BOM. For those programs, typically a working-tree encoding is important so that Git will internally store them as UTF-8 text and can do things like diffs and merges on them. It is the case that most editors and tools these days handle UTF-8 and LF just fine, which is probably why you haven't really seen problems.
I do strongly recommend at least a simple * text=auto if nothing else if your project will be used on Windows, because it means that people will not accidentally commit CRLF line endings in your text files and also that people will have the line endings they prefer when working across systems. It's a simple step that can make the experience with your project a lot better.