• @onlinepersona
    link
    English
    357 months ago

    Maybe it’s time for windows to stop using CRLF and join the modern world?

    • Kogasa
      link
      117 months ago

      Not backwards compatible, will never ever happen

      • @namingthingsiseasy
        link
        87 months ago

        Guess we’ll just have to deprecate the entire Windows OS then…

    • @lysdexicOP
      link
      English
      -17 months ago

      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?

      • @onlinepersona
        link
        English
        87 months ago

        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.

        • @lysdexicOP
          link
          English
          -1
          edit-2
          7 months ago

          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.

          • @onlinepersona
            link
            English
            47 months ago

            which is the case of the whole ASP.NET stack.

            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.

            • @lysdexicOP
              link
              English
              07 months ago

              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.

  • @lysdexicOP
    link
    English
    167 months ago

    For those who want a ready-made set of .gitattribute files you can simply drop on your project, here’s this fancy GitHub link.

    https://github.com/gitattributes/gitattributes

    Once you add a .gitattributes file to your project, make sure you push a commit that re-normalizes all relevant files:

    git rm --cached -r .
    git reset --hard
    
    • @boomzilla
      link
      1
      edit-2
      7 months ago

      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 reset only from dealing with a detached HEAD. I did not understand the situation as well as the git reset command. 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: Normally git rm would 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 do git add again for every file but you wouldn’t have lost any uncommitted changes in the working dir.

      Now for the dangerous part:

      git reset --hard This 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].

      [2]

  • @[email protected]
    link
    fedilink
    8
    edit-2
    7 months ago

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

    They don’t even use a proper operating system that respects the user. Instead they go for some big tech OS from fucking Microsoft.

    • @lysdexicOP
      link
      English
      77 months ago

      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.

    • @[email protected]
      link
      fedilink
      57 months ago

      Think about it this way: by making their lives easier, you make life easier for yourself, too. It doesn’t take a lot of effort to put a proper .gitattributes file in your repo, but in return, you’ll nip any potential future issues from Windows users who are trying to contribute accidentally or unknowingly checking in files with the wrong line endings.

      Inb4 “I don’t care about contributions from Windows users anyways”: a lot of apps are multiplatform these days (usually Electron). It’s unreasonable to expect people to do all their coding in Linux and only use Windows for testing, especially when all the tooling already exists on Windows. VS Code will handle a repo with LF line endings just fine as long as you told git not to convert the line endings when checking out.

    • @BatmanAoD
      link
      17 months ago

      Mac OS is also a big tech OS and arguably doesn’t respect the user.

      Linux is nice but often not an option for devs for circumstantial reasons, such as needing to use a corporate-provided machine for work.

  • @[email protected]
    link
    fedilink
    English
    27 months ago

    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.

    • @lysdexicOP
      link
      English
      11
      edit-2
      7 months ago

      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.

  • @muhanga
    link
    -27 months ago

    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.