Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The issue of EOLs in mixed-platform projects has been making my life miserable for a long time. The problems usually arise when there are already files with different and mixed EOLs <em>already</em> in the repo. This means that:</p> <ol> <li>The repo may have different files with different EOLs</li> <li>Some files in the repo may have mixed EOL, e.g. a combination of <code>CRLF</code> and <code>LF</code> in the same file.</li> </ol> <p>How this happens is not the issue here, but it does happen. </p> <p>I ran some conversion tests on Windows for the various modes and their combinations.<br> Here is what I got, in a slightly modified table:</p> <pre> | Resulting conversion when | Resulting conversion when | committing files with various | checking out FROM repo - | EOLs INTO repo and | with mixed files in it and | core.autocrlf value: | core.autocrlf value: -------------------------------------------------------------------------------- File | true | input | false | true | input | false -------------------------------------------------------------------------------- Windows-CRLF | CRLF -> LF | CRLF -> LF | as-is | as-is | as-is | as-is Unix -LF | as-is | as-is | as-is | LF -> CRLF | as-is | as-is Mac -CR | as-is | as-is | as-is | as-is | as-is | as-is Mixed-CRLF+LF | as-is | as-is | as-is | as-is | as-is | as-is Mixed-CRLF+LF+CR | as-is | as-is | as-is | as-is | as-is | as-is </pre> <p>As you can see, there are 2 cases when conversion happens on commit (3 left columns). In the rest of the cases the files are committed as-is.</p> <p>Upon checkout (3 right columns), there is only 1 case where conversion happens when: </p> <ol> <li><code>core.autocrlf</code> is <code>true</code> <em>and</em> </li> <li>the file in the repo has the <code>LF</code> EOL.</li> </ol> <p>Most surprising for me, and I suspect, the cause of many EOL problems is that there is no configuration in which mixed EOL like <code>CRLF</code>+<code>LF</code> get normalized.</p> <p>Note also that "old" Mac EOLs of <code>CR</code> only also never get converted.<br> This means that if a badly written EOL conversion script tries to convert a mixed ending file with <code>CRLF</code>s+<code>LF</code>s, by just converting <code>LF</code>s to <code>CRLF</code>s, then it will leave the file in a mixed mode with "lonely" <code>CR</code>s wherever a <code>CRLF</code> was converted to <code>CRCRLF</code>.<br> Git will then not convert anything, even in <code>true</code> mode, and EOL havoc continues. This actually happened to me and messed up my files really badly, since some editors and compilers (e.g. VS2010) don't like Mac EOLs.</p> <p>I guess the only way to really handle these problems is to <em>occasionally</em> normalize the whole repo by checking out all the files in <code>input</code> or <code>false</code> mode, running a proper normalization and re-committing the changed files (if any). On Windows, presumably resume working with <code>core.autocrlf true</code>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload