Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
normalise and enforce correct line endings #61
I've still seen a few files cropping up with mixed line endings even when using autocrlf=true, which is strange.
I think if we do a one-off normalisation and enforcement using gitattributes then we should kill this problem once and for all.
Note that we need to run a one-off build on the build server with 'clean all files in checkout directory before build' switched on after making this change.
Hy, yes gitattributes solves this. And it let's you define how git should treat various files in the repo. Important is this
$ define gitattributes in .gitattributes
BTW - the workflow suggested by GitHub is the following. I guess it would have an equivalent outcome.
$ git add .gitattributes $ git commit -m "Add gitattributes" $ git rm --cached -r . $ git reset --hard $ git add . $ git status $ git commit -m "Normalize line endings"
I guess the only thing we need to decide now is what our policy is.
Before the proposal to add gitattributes, we'd decided to stick with autocrlf=true to save any awkward transition and risk of people not making the switch. However, if we are going to bake the setting into the repo then we have the freedom to choose whatever policy we want.
My vote still goes with no line ending tampering at all (equivalent of
If I'm not mistaken, with gitattributes this could be achieved by the file contents being simply
I.e. treat every file as binary and don't attempt to change any line endings. I think the simplicity of this setting is an advantage in itself, i.e. if wanted to use line ending conversion then we'd have the maintenance overhead of a file such as https://github.com/danielmarbach/appccelerate/blob/master/.gitattributes
OK, this doesn't work
# .gitattributes * binary
# .gitattributes * -text
does the trick.
I followed the steps suggested by GitHub and now I have files with both types of line endings in my clone, i.e. no conversions have taken place and I see the real line endings which are in the repo.
I also have no further changes to commit since no normalization at all is required. This is another advantage of this approach.
added a commit
Mar 7, 2013
I don't but it is in the end a matter of taste so no arguments against it from my side
Am 08.03.2013 um 08:47 schrieb Philipp Dolder email@example.com:
Something to note regarding this. If we do switch off line ending conversion we'll have to do a one off fix of any files which contains a mix of LF and CRLF. Otherwise VS seems to decide to align the line endings of it's own accord when you edit a file and this can be very disruptive.