• lysdexic@programming.devOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 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
    
  • gatelike@feddit.de
    link
    fedilink
    English
    arrow-up
    0
    ·
    10 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.

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      10 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.

  • 1984@lemmy.today
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    10 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.

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 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.

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 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@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        arrow-down
        1
        ·
        10 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.

        • lysdexic@programming.devOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          10 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.