Skip to content
loading...

πŸ™ Please Add .gitattributes To Your Git Repository

deadlybyte 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]
markdown guide
 

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)

See also: help.github.com/en/github/using-gi... and git-scm.com/docs/gitattributes

 

I admit to still typing notepad into Run/cmd/PS on occasion, but I swear it's only for notes I plan to throw away quickly lol. Don't hate me though; even though I'm a long time Win user, I'm also a long time ^(Li|U)n(ux|ix)$ user :D

Thanks for this tip, by the way...

 
 

I admit to still typing notepad into Run/cmd/PS on occasion, but I swear it's only for notes I plan to throw away quickly lol

Literally me, lol!

Windows + R, type notepad, and then dump my thoughts in there from time to time (usually my TODOs for the day). It's good to have such a minimal editor on hand, without all those UI distractions.

 

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/

 
 

Thanks for this additional information. Please NO, not Notepad!!! πŸ˜€

 

Haha I moved to macOS at the start of the year and I miss notepad. :P

TextEdit can be configured close but it's not the same.

I also never realised how much I used WIN+R as a quick scratchpad when I found myself distracted by another task but still had something live in my clipboard.

Check out Quiver for macOS. Create notes within notebooks, and each note can have cells of markdown, code blocks, or sequence diagrams.

happenapps.com/#quiver

For other platforms, check out Joplin. It's not as nice as quiver, but shares some of the same ideas.

I miss that app so much... I switched to Linux from Mac OS a while ago, and that one was one of my most favorite productivity apps.

My crude workaround at the moment is Typora. It's not bad, but not nearly as polished as Quiver.

I will check out Joplin soon. Thanks for the tip!

Currently using Joplin. It is amazing, and a quick look at Quiver yields a very similar look. I don't know of any implementation that allows "sharing" notebooks like I saw in a screenshot of Quiver, but otherwise, Notebooks with sub-notebook organization, Markdown is possible. Also, there seem to be a lot more methods for accessing Joplin on different platforms, with Windows/MacOS/Linux/Android/iOS/Terminal implementations with DropBox and other file storage services. Highly recommended.
Also, Joplin is FREE. Major bonus.

 
 

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

 

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

 

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.

 

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

 

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

 

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.

 
 

My question is - why do you even have that prettier rule? Why do you force a particular line ending style?
IMO the proper fix for the problem you have is to relax the rule - change it to forcing a uniform line ending style across the file, not a particular one.

I am generally against using a code repository to modify files in any way. What next - server-side merges?

 

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.

 

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

 

.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...

 

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?

 

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)

 

😐

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

 

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

Source: stackoverflow.com/a/47868908/1118446

 

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

 

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.

 

Good article! Another cool thing you can do with the .gitattributes file is keep your tests out of other people's projects (or even keep your .gitattributes file out of their projects) by using the export-ignore option.

 
 

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

 

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.

 

What's the difference between CR LF, LF and CR? As far as I know all three do the same these days.
To sum it up:

  1. You don't see the character
  2. The output is the same (file size negligently bigger in case of CRLF)
  3. No added value of using one over the other.

I think this should be ignored in prettier.

Focus on something that actually has a visible effect, don't try to fix something for the sake of OCD satisfaction.

 

Should your

git rm --cached -r

command be this instead?

git rm --cached -r .
 
 

Why there is --cached in git rm as it makes no difference in the final result?
Am I missing some thing?

 

Hi, it's a really nice article, can I translate it into French?

 

Thanks, sure happy for it to be translated into any language.

 

The git command 'git rm --cached -r' does nothing but show me usage options! So which file(s) are we removing from the cache

 

I've fixed the git command, as it should of been.

git rm --cached -r .
 

I think gitattributes should be used as a patch fix, not a planned solution... Like, your linting/styling decisions for a repo should be enforced at the file level, not at the commit level usually

 

Why don't you just configure that editor|IDE?

 

this may take longer than creating a single file with maybe 1 line :)

 

Yet another way to avoid petty developer flame wars. Thanks for this.

 
 

Hello

There is also this question on stackoverflow:
stackoverflow.com/questions/150901...

But good thing you're bringing this to attention!

 
 
 

For commen formatting rules we use the .editorconfig

 
 

Never knew that... Now I do!

Thanks for this post!

 
 

I must to show this to my team lead and team. Thx!

 

No worries, hope your team implement it.

code of conduct - report abuse