lysdexic

Cpp should have done ref by default and had & for copy, but here we are.

That would defeat the goal of making it backwards-compatible with C.

They used it because it was an established term

My graph theory is a bit fuzzy but I think that the definition of a branch in a directed graph corresponds to the path between two nodes/vertices. This means that by definition any path from the root node to any vertex is itself a branch.

I don't think Git invented this concept, nor did any other version control system.

I know that “branch” helps intuitively and visually when it’s actually an offshoot with one root and a dangling tip, like an actual tree branch…

I think that your personal definition of a branch doesn't correspond to what graph theory calls a branch. Anyone please correct me if I'm wrong.

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.

If a library or framework requires boilerplate code it’s a bad library or a bad framework.

I think this take is uneducated and can only come from a place of inexperience. There's plenty of usecases that naturally lead to boilerplate code, such as initialization/termination, setting up/tearing down, configuration, etc. This is not a code smell, it's just the natural reflection of having to integrate third-party code into your projects.

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, .gitattributes is already hidden.

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.

That’s right, hence wanting a MAUI community

I'm not sure we are on the same page.

Creating a community does not create traffic out of thin air. Either we have people interested on the topic, or we don't.

Right now there are barely any users interested in .NET, and MAUI has a potential userbase that represents a small subset of the whole .NET userbase.

Knowing this, what exactly leads you to believe that a post volume that barely goes above 1 post per day requires forking the original community to host a small subset of that traffic?

My recommendation is that before you go about wanting to create niche communities forked out of other niche communities, you should focus your efforts on generating traffic in the communities that already exist. It would be ok if the request was for creating a community to an entirely different programming language/tech stack, but this isn't it. It's a request to create a community dedicated to a niche framework that's already a part of another framework for which there's already a community that's nearly dead. Again, about 3/4 of all communities in programming.dev barely register 1 active user/month. What's the value of creating yet another dead group?

I read your other reply. I don't think it holds water. To me the volume of traffic that's hitting !dotnet@programming.dev and even !nodejs@programming.dev, !ruby@programming.dev, !mongodb@programming.dev, etc already shows that it's not reasonable to expect users to flock here just because there's a community.

Either you build niche communities to accommodate today's users, or you create them hoping that new users will flock here. A brief look at the long tail of communities in programming.dev will tell you that nearly 3/4ths of the communities already created register less than 5 users per month.

#dotNetMAUI has been used in posts 33 times in the last 26 days

That largely corresponds to slightly over 1 post per day. That traffic ceiling is way higher than the traffic going into !dotnet@programming.dev

IMHO it’s unnecessary at this juncture, and further fragments already vastly under engaged communities (.Net & C#)

I wholeheartedly agree. !dotnet@programming.dev currently gets an average of around 4 posts per week. from which zero tend to be about MAUI. I don't think there's a need to cut out a separate community to filter out discussions on topics that aren't being discussed.

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?

So we should use this to make life easier for Windows users, mainly? Hmm.

I think this might be helpful for teams who use an heterogeneous set of platforms to checkout and work on their code. Windows is one of them, although in this day and age it's also possible to configure IDEs to do the right thing.

Another important usecase for .gitattributes is to force some file types to be handled as binary data types instead of text, and thus support different types of diff mechanisms. Case in point, a while back there was a discussion on how to track sqlite databases in a git repository in a way that a) the database file wasn't mangled, b) git diff actually outputted changes to the database instead of random noise. This stuff is handled at the .gitattributes level.