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.
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.
99% of all servers a unix, which means code written for servers
This is where you start to get things the wrong way.
The code that runs on a server isn’t necessarily built from source code in the same platform. You can easily have entire teams working on Windows on projects that incidentally only run on Unix-like OSes after they are deployed, which is the case of the whole ASP.NET stack.
It makes no sense to dictate what newline character you enforce a project based not on which platform a team will use to work on the source code but on whatever platform the project may or may not be deployed.
This approach is particularly absurd once you take into account the fact that Git supports line ending normalization, and it supports configuring which newline is used when checking out source code not only in a per-repository basis but also on a per-user and even per-local repository basis.
ASP.NET? The microsoft technology? That runs mostly on IIS? Yeah, that’s not a good example.
This approach is particularly absurd once you take into account the fact that Git supports line ending normalization, and it supports configuring which newline is used when checking out source code not only in a per-repository basis but also on a per-user and even per-local repository basis.
I find it absurd to make a plaidoyer to all git users to add another file to their repo to placate those unable, unwilling, or ignorant to adhere the standard.
ASP.NET? The microsoft technology? That runs mostly on IIS?
No, by ASP.NET I was referring to ASP.NET Core, whose latest LTS version was released along .NET 8.
I find it absurd to make a plaidoyer to all git users to add another file to their repo to placate those unable, unwilling, or ignorant to adhere the standard.
You only speak for yourself, and your comment clearly showed you were ignorant of some basic usecases that are behind the feature you were criticizing.
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.
This is where you start to get things the wrong way.
The code that runs on a server isn’t necessarily built from source code in the same platform. You can easily have entire teams working on Windows on projects that incidentally only run on Unix-like OSes after they are deployed, which is the case of the whole ASP.NET stack.
It makes no sense to dictate what newline character you enforce a project based not on which platform a team will use to work on the source code but on whatever platform the project may or may not be deployed.
This approach is particularly absurd once you take into account the fact that Git supports line ending normalization, and it supports configuring which newline is used when checking out source code not only in a per-repository basis but also on a per-user and even per-local repository basis.
ASP.NET? The microsoft technology? That runs mostly on IIS? Yeah, that’s not a good example.
I find it absurd to make a plaidoyer to all git users to add another file to their repo to placate those unable, unwilling, or ignorant to adhere the standard.
No, by ASP.NET I was referring to ASP.NET Core, whose latest LTS version was released along .NET 8.
You only speak for yourself, and your comment clearly showed you were ignorant of some basic usecases that are behind the feature you were criticizing.