Please Add .gitattributes To Your Git Repository
Please Add .gitattributes To Your Git Repository
Article explaining why .gitattributes is important for configuring a consistent end of file ending in a git repository used by multiple team members on different OSes.
Maybe it's time for windows to stop using CRLF and join the modern world?
Not backwards compatible, will never ever happen
Guess we'll just have to deprecate the entire Windows OS then...
Maybe it’s time for windows to stop using CRLF and join the modern world?
Why do you think there is a problem and that's a solution?
99% of all servers a unix, which means code written for servers (to run on them or be built by them) should be using LF, nor CRLF. It should be up to windows users to set their editors to use LF or create .gitattributes to follow the quasi-standard. The rest of the world shouldn't have to adapt and accomodate devs outputting CRLF.
For those who want a ready-made set of
.gitattributefiles you can simply drop on your project, here's this fancy GitHub link.https://github.com/gitattributes/gitattributes
Once you add a
.gitattributesfile to your project, make sure you push a commit that re-normalizes all relevant files:git rm --cached -r . git reset --hardWhere JavaScript?
Thanks. I somehow straight-up ignored gitattributes and can't recall to have seen them in projects. Glad that's past tense now and I will add presets from your link where appropriate (If I remember it). Never had conflicts with windows users on linux based repos but I suspect thats VSCodes merit in keeping the files as-is.
The two commands in your post are not mentioned in the linked repo-readme but instead in the github docs (see [1]).
I know
git resetonly from dealing with a detached HEAD. I did not understand the situation as well as thegit resetcommand. Both is explained very good in [2].So here's the gist of my research (possibly wrong).
Before you even add the .gitattributes file you should add all unstaged changes, commit & push them. To quickly revert back when things go wrong: zip the whole project.
git rm --cached -r: Normallygit rmwould remove a file from the filesystem in addition to the repo but the --cached says to only remove/untrack the file from the repo (what's inside the .git dir). Recursively removes every file. Cleans the current staging area too. So at this point you'd have to dogit addagain for every file but you wouldn't have lost any uncommitted changes in the working dir.Now for the dangerous part:
git reset --hardThis resets the HEAD to the most recent commit (and cleans the staging-area/index which was already done in the in git rm) and in addition possibly overwrites many unstaged/uncommitted changes with the files contents from the last commit.So to end this novel. If you havent commited everything before executing the commands your in for a bad time. As far as I see it.
[1].
no. I'm sick of cicd pollution in my project dir. Git, Gradle, cloud build, Jenkins, docker. All that shit needs to go under hidden folders. Also while I'm ranting fuck carriage returns and people with tabs set to 8.
no. I’m sick of cicd pollution in my project dir.
This is about configuring the version control system you use to track your software. It has absolutely no relation with CICD systems.
All that shit needs to go under hidden folders.
On unix-like platforms, dot files are interpreted as hidden files. By design,
.gitattributesis already hidden.
If you use a programming language which behaviour depends on the symbols that you hiding 90% of the time (I am talking about line ends and whitespace types) you will have a bad time. No amount of gitattributing or autocrlf magic will save you. You will suffer and you will get a phantom bugs if your editor and diff viewer will not show you "whitespace" changes.
And at the same time any programming language that will break due to whitespace should be chastised and laugh upon. Whitespace type should never be significant modifier for behaviour.
Also YAML can fuck off right into the sun.