#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2015
    Posts
    10
    Rep Power
    0

    GIT autocrlf confusion


    I didn't know where else to put this since this question is strongly tied to .NET development.

    The story is this: At work we've started to use GIT as our SCM, which is nice and all while it was all among full time developers. But ever since some PM's have started to pitch in we've had the occasional hiccup with line endings being messed up. Now I'm in a heated debate with said PM about how to handle this issue.

    His stance is: Leave everything on their defaults. As little rules as possible so everyone does things the same. (A commendable ideal in my mind but unfortunately "Git for Windows" defaults to setting autocrlf to true)

    My stance is: The setting should be determined by the needs of the project. The vast majority of our projects are only worked on under windows and only run under windows. Why on earth would I want some tool magically messing with my line endings? And the few non windows projects can handle this however it is best for them. With the .gitattributes file we now have the option to force an appropriate setting on all users of a repository.

    What is the ideal approach?
  2. #2
  3. Forgotten Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,046
    Rep Power
    9616
    The ideal approach is whatever works. If your project manager's stance works then that's what you'll be using. If it does not then you (two) need to identify precisely why it does not work and what you can do to fix it, be that editor settings or git settings.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2015
    Posts
    10
    Rep Power
    0
    Well, the problem is that neither of us is in a good position to argue since neither of us really understands the system.

    His approach is "Leave everything at defaults and hope for the best".
    While mine would be "Understand the implications of each setting and adapt them to the needs of each project".

    But without some idea about that it is hard to argue with him and becaue once we have a mix of line endings in a project it's impossible to fix it because it would make him unable to compare changes.

    Question 1: If we were to set all installations of git to autoconvert. On Windows the autocrlf would turn files CRLF->LF(git) on checkin and LF->CRLF(native) on checkout. And on a hypothetical Linux installation it would simply run CRLF->LF(git) on checkin and LF->LF(native) on checkout. Right?

    Question 2: This is the equivalent (with the exception of enforcing this behavior on all contributers) of the following .gitattributes, right?
    * text=auto
    [core]
    eol=native

    Question 3: Am I correct in my understanding that the current line in our .gitattributes (see below) ensures that line endings are committed as they are?
    * text=unset

    Question 4: If a wildcard pattern is used in .gitattributes (ie: * text=auto) then a subsequent, more specific pattern (ie: *.sln eol=crlf) would override both the categorization and the core.eol setting for solution files, right?
  6. #4
  7. Forgotten Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,046
    Rep Power
    9616
    Side comment: I'm surprised that line endings are an issue. Don't people use editors that can handle them gracefully? My NetBeans does CR/CRLF/LF with no problem.

    Originally Posted by Kempeth
    His approach is "Leave everything at defaults and hope for the best".
    While mine would be "Understand the implications of each setting and adapt them to the needs of each project".
    Go for the middle ground: understand the implications of the settings, start with them at their defaults, see what happens, and adjust accordingly.

    Originally Posted by Kempeth
    But without some idea about that it is hard to argue with him and becaue once we have a mix of line endings in a project it's impossible to fix it because it would make him unable to compare changes.
    Every diff/merge tool I've seen has an option to ignore line endings. I always have that turned on. I typically turn on an option to ignore inline whitespace too.

    Originally Posted by Kempeth
    Question 1: If we were to set all installations of git to autoconvert. On Windows the autocrlf would turn files CRLF->LF(git) on checkin and LF->CRLF(native) on checkout. And on a hypothetical Linux installation it would simply run CRLF->LF(git) on checkin and LF->LF(native) on checkout. Right?
    With the "true" and "input" settings, respectively, yes.

    Originally Posted by Kempeth
    Question 2: This is the equivalent (with the exception of enforcing this behavior on all contributers) of the following .gitattributes, right?
    * text=auto
    [core]
    eol=native
    I'm not sure there's an "eol=native" setting, but otherwise yes.

    Originally Posted by Kempeth
    Question 3: Am I correct in my understanding that the current line in our .gitattributes (see below) ensures that line endings are committed as they are?
    * text=unset
    Yes.

    Originally Posted by Kempeth
    Question 4: If a wildcard pattern is used in .gitattributes (ie: * text=auto) then a subsequent, more specific pattern (ie: *.sln eol=crlf) would override both the categorization and the core.eol setting for solution files, right?
    I don't know. Educated guess would say that git will process top-to-bottom looking for a pattern match, so put *.sln before *.

    Try it and find out - the messages during a commit would be enough to tell what git is doing.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2015
    Posts
    10
    Rep Power
    0
    Originally Posted by requinix
    Side comment: I'm surprised that line endings are an issue. Don't people use editors that can handle them gracefully? My NetBeans does CR/CRLF/LF with no problem.

    Every diff/merge tool I've seen has an option to ignore line endings. I always have that turned on. I typically turn on an option to ignore inline whitespace too.
    The problem are not the diff *tools*. He uses kdiff3 which ingnores those by default. The problem is the git integration. He uses Tortoise git which to my knowledge does not have such a setting. I've just yesterday discovered that the tool I prefer (SourceTree) has such a setting. I will see if that can ease the situation.

    Also thank you for the other points. I'll see if I can do some experiments to confirm the remaining questions.
  10. #6
  11. Forgotten Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,046
    Rep Power
    9616
    What setting? I've seen autocrlf before, in the... config pages?

IMN logo majestic logo threadwatch logo seochat tools logo