If I understand correctly, then in windows with autocrlf = true Git will do the CRLF -> LF conversion after the commit, and LF -> CRLF when the checkout is done.

In my workflow, there are cases when the source files are reset manually, bypassing the repository, from the working directory of the repository of the first Linux / Windows machine to the working directory of the second Windows machine.

In this case, the lines in these source files contain the LF ending, and in the working directory of the second CRLF machine. Does this mean that you have to manually convert them with third-party software to CRLF mind?

How to properly configure core.autocrlf on both working machines to avoid errors during "manual" file transfer?

I assume that in Windows, autocrlf = true , and in Linux, autocrlf = input (to prevent the case above, only with CRLF ).

    2 answers 2

    How to properly configure core.autocrlf on both working machines to avoid errors during "manual" file transfer?

    I think it makes sense in all operating systems to assign this attribute at least the value of input .

    then when adding β€œnon-normalized” files (i.e., crlf line delimiter ), a warning will be issued that the file in the repository will be converted, and the subsequent commit will automatically β€œnormalize” the file ( crlf separator will be replaced by lf ).

    and when the checkout command is executed, no conversions will be made - the files in the working copy will have the same separators as in repository 1 .

    perhaps in operating systems, where the default delimiter is not lf , but crlf (for example, ms / windows ), it makes sense to β€œgo further”, and set the core.autocrlf attribute to true β€” so that , with the checkout command, the conversion lf β†’ crlf is performed . but it probably makes sense only if the program used to view / edit these files displays the contents of the files incorrectly (i.e., does not make a line break when it encounters the lf symbol).

    1 - see how the file is stored in the repository, for example, using the git cat-file -p Ρ…ΡΡˆ . example:

    initialize the repository:

     $ git init

    add two lines to the file and commit:

     $ echo 1 > file; echo 2 >> file $ git add file $ git commit -m 1 [master (root-commit) 1373ad1] 1 1 file changed, 2 insertions(+) create mode 100644 file

    view the contents of the commit by specifying its hash (can be abbreviated):

     $ git cat-file -p 1373ad1 tree d25d3b6082891168b6787cb20783bd332e5b8f74 ...

    view the object of type tree added by this commit:

     $ git cat-file -p d25d3b6 100644 blob 1191247b6d9a206f6ba3d8ac79e26d041dd86941 file

    view the blob object containing the same file:

     $ git cat-file -p 1191247 | hexdump -C 00000000 31 0a 32 0a |1.2.| 00000004

    and see that it is preserved in the repository with the lf line delimiter.

      I tested all the options and here's what happened:

       ╔═══════════════╦══════════════╦══════════════╦══════════════╗ β•‘ core.autocrlf β•‘ false β•‘ input β•‘ true β•‘ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ β•‘ git commit β•‘ LF => LF β•‘ LF => LF β•‘ LF => CRLF β•‘ β•‘ β•‘ CR => CR β•‘ CR => CR β•‘ CR => CR β•‘ β•‘ β•‘ CRLF => CRLF β•‘ CRLF => LF β•‘ CRLF => CRLF β•‘ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ β•‘ git checkout β•‘ LF => LF β•‘ LF => LF β•‘ LF => CRLF β•‘ β•‘ β•‘ CR => CR β•‘ CR => CR β•‘ CR => CR β•‘ β•‘ β•‘ CRLF => CRLF β•‘ CRLF => CRLF β•‘ CRLF => CRLF β•‘ β•šβ•β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•©β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•©β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•©β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•

      I believe that the most optimal option on all systems is core.autocrlf = input . At the same time, on all OSes, the end of the CRLF lines, if necessary, will be implicitly converted to LF , if there is already an LF , it will remain so.