DEV Community

🙏 Please Add .gitattributes To Your Git Repository

Carl Saunders on February 03, 2020

What Is .gitattributes? The .gitattributes file allows you to specify the files and paths attributes that should be used by git when per...

Read full post

Thomas Werner • Feb 3 '20

There's also an option that makes everyone happy: Let the git installation on a user's machine decide which line ending to use when a repository is checked out:

* text=auto

That way it really doesn't matter and Windows users can still open their files using Notepad if they wish (I'm not judging 😄).

AFAIK line endings are committed to the repository "normalized" as LF, but the checked out version depends on the OS default for line endings.

The setting can be also fine tuned with additional overrides in case there are specific file types that need their line endings preserved (e.g. shell scripts or Windows batch files)

Comment deleted

Ben Sinclair • Feb 4 '20

Ah, the glory days of Unux and Linix.

Charles Roper • Feb 11 '20

Install Notepad2-mod, choose to replace Notepad when you install it, and you'll get all the lightweight joy of old Notepad with just enough extra sprinkles (like lf support and syntax highlighting) to make it practical.

xhmikosr.github.io/notepad2-mod/

Hải • Oct 7 '20

I'm a heavy Windows desktop user. But live primarily in wsl terminal nowadays.

Btw, that Regex would match Unux😝

Randall • Oct 16 '20

As a (mainly) Windows user I always disable autocrlf and standardize on LF because:

If I'm building Docker images (and I often am), I don't want to be copying CR LF files into the Docker images. Some Linux utilities will choke on them.
If my program reads, say, XML files, I don't want the (multiline) strings going through my code to differ depending on my OS, this has bit me before too.
If I calculate a hash on a file I want it to be the same on any OS.
While I have had problems with CR LF files on Linux, I have never had problems with LF files on Windows (I don't use Notepad).

Abel Lifaefi Mbula • Feb 4 '20

I use editorconfig, I'm OK with it.

vrushank • Mar 7 '23

We also thought the same that using editor config should be fine but it does not help while team working on cross platform environment. It is always better to define line endings using .gitattributes file.

Jesse Phillips • Feb 3 '20

Git should force all committed files to use lf stop entertaining the idea windows choice has any merit.

Thomas Werner • Feb 3 '20

Those line ending characters used to be control characters for teletypewriters (TTY). CR (carriage return) would tell the device to move the carriage (or print head or whatever) back to the beginning of the current line. Another LF (line feed) control character was necessary for moving the paper to the next line. It was not really a Windows choice or invention. Windows got it from MS-DOS to stay backwards-compatible and MS-DOS got it from CP/M, an OS from the 1970ies, and overall this is how TTYs worked. They needed CR and LF for doing the right thing.

The makers of Unix on the other hand decided that LF would be enough to tell a device driver to send the correct control sequence for moving to the beginning of the next line.

So in the olden days CRLF was a safer choice to control a teletypewriter.

AFAIK CRLF is still the full control sequence that is internally used by modern consoles and terminal emulators for moving the text cursor on the screen to the beginning of the next line. Hitting the Enter key produces just the CR control character. The terminal software automatically adds an LF to it

Jesse Phillips • Feb 3 '20

I realize this, and until recently both were needed for notepad to show new lines.

My point is we don't feed this to tty and when we do it is already worked out because recourse is no constrained.

Carl Saunders • Feb 3 '20

Yep, fully agree. I'm a Windows user and always set the eof to lf no matter what.

José Coelho • Feb 3 '20 • Edited

I think that for the use case you presented the git core.autocrlf config option is more appropriate.
With this option each developer can work with their native eol character.

However what I like about your option is that you can commit the gitattribute file and force the change for every developers

Andrei Dascalu • Feb 3 '20

You're not really forcing it if you need to ask everyone to flush their cache / reset gitattributes.
If you need cooperation, it's better to just ask developers to set their autocrlf setting properly.
Prettier issue aside, it's better to preempt accidental commits of eol changes anyway.

Carl Saunders • Feb 3 '20

Thanks for the tip.

Shane Knudsen • Feb 10 '20

Aside from issues with prettier, we get the occasional problem where changing the eol character(s) causes a file to show up in source control as if it's been changed.

Much worse, I used to write a bunch of BASH scripts meant to be run on both Linux and Windows machines (under Cygwin). Every so often, somebody would edit the file on a Windows machine, commit it, and then the script would fail to run on the Linux machines because of the line endings. Me and dos2unix got to be good friends.

Hải • Oct 7 '20

I love dos2unix too, occasionally do clippaste | dos2unix for Windows clipboard to work correctly in Wsl.

Carl Saunders • Feb 10 '20

Yeah, I had this same problem with Linux scripts at my old work place too.

Lee Hyeon-Soo • Feb 10 '20

.gitattributes in GitHub

.gitattributes is also used to get Github to calculate language statistics and display the correct primary language for a repo.

Check out github.com/github/linguist#using-g...

Josh • Feb 4 '20 • Edited

Seems to me like the linter could worry less about something that's no fault of any developer on the team, and more about ...

🤔

Actually, why do we have tools that make our codebases more opinionated about formatting than the languages themselves are? Do we not trust that we – or our coworkers – are grown adults, with a basic grasp of readable source? How did linters come to rule the world?

jastuccio • Feb 11 '20 • Edited

How did linters come to rule the world?

Our "grown adult co-workers" used to go to war over things like tabs vs spaces, semicolons in JS, and a lot of other stuff. Prettier came along and made an easy to use tool that said "THESE ARE THE RULES. Now be quiet and get back to actual work" I don't think it was even configurable when it came out (or at least severely limited as to what could be customized)

Josh • Feb 12 '20 • Edited

😐

What a stupid thing to go to war over in the first place. They've heard of "writing style" and "aesthetic", right?

Darryl • Aug 18 '20

There were a lot of justifiable reasons these wars happened, and some of them are still valid. Imagine a text editor that interprets a tab as "move to the next column that's a multiple of 8" with no way to configure it to do otherwise. Mix tabs and spaces together and what was nicely lined up for you is completely unreadable to me. Or how about 1 tab = 12 spaces, on an 80 character wide screen? Yeah, that was a thing. These examples aren't an issue any more, but other things are, like code editors that automatically reformat things. If you don't standardize or otherwise keep things in check, you can never tell what actually changed from one commit to the next.

Josh • Aug 24 '20 • Edited

Or how about 1 tab = 12 spaces, on an 80 character wide screen? Yeah, that was a thing.

My inkling is that the developer who had that rule was either not using a lot of tabs, using a screen a few more than 80 characters wide, or had some other environmental rationale for why they had adopted what seems, to you and I, an exorbitant amount of spacing for our specific environments. If they were working in a new environment where such spacing was no longer reasonable, or if there was a better standard of spacing in their own environment, I maintain that you (or the colleague who pointed it out to you) found yourself at the crux of a teaching opportunity as opposed to the heart of a war-invoking, crucial difference in the ways different people see the world we share.

I continue to draw countless lessons from the time I spent working at Pivotal, where the Tracker team established the code-formatting rule:

If a pair commits code that's legitimately unreadable, it is a call to reassess our hiring policies, writ large. If it is unfamiliar, but still readable, it is an opportunity to ask and learn why the pair determined the feature necessitated this style for the code. In this case, whether we take the opportunity to learn its motivations or not, if it resolves the ticket and doesn't break integration tests, leave it alone until you have actual work you need to do in that part of the codebase.

(EDIT: My words seem to have reverberated through the collective subconscious [no they didn't] and land in the latest update to Visual Studio Code. In spite of everything else, at least people can say I'm prett yified.)

It might sound crazy to most of the people here, I know, but in short, the way we stopped having endless arguments about code formatting, was to stop having endless arguments about code formatting.

Norah Medlin • Feb 11 '20

For those using .editorconfig INSTEAD of .gitattributes, please keep in mind that not all editors support .editorconfig :)

Source: stackoverflow.com/a/47868908/1118446

Patryk Bernasiewicz • Feb 11 '20 • Edited

We don't use linters at work, so we don't have problems with cross-platform line-ending issues.

AngularNodeJS 🚀 • Feb 11 '20

This is pretty good advice. I have been using a combination of editorconfig files with pre-commit hooks to run linting and formatting which enforces 'eol'.

Your solution is more elegant. Reading the github reference on this, it might be better to do it this way, using auto.

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

*.js    text
*.jsx   text
*.json  text

This way, whatever OS you are no, git will decide the correct 'eol' to apply for you.

Bhaskar • Feb 6 '20

Alternatively we can use editorconfig. editorconfig.org/

Cherny • Feb 11 '20

I tried this but it comes with the exception for medium/large companies where devs just don't care too much about that and use any editor they want without built-in or plugin support for editorconfig

Xandor Schiefer • Feb 11 '20

Another great use-case for .gitattributes is to mark certain text files as binary. I do this with lock files and other machine-generated files which should be committed to the repo.

This way, when looking through diffs in the history, the staging area, or even on hosted Git platforms, these files no longer add to the noise.

Andrew Lane • Feb 11 '20

Should your

git rm --cached -r

command be this instead?

git rm --cached -r .

Carl Saunders • Feb 11 '20

Yep, good spot. I'll change it now.

roadpepe • Jan 2 '22

If you are lazy and want to quickly add a .gitattributes to your project but don't want to create one from scratch, you could use github.com/alexkaratarakis/gitattr... for a template. It's quick, simple and supports most common languages.