windows - whatwg - w3c html standards

Git en Windows: ¿Qué significa la configuración crlf? (3)

Exploré 3 valores posibles para casos de compromiso y pago y esta es la tabla resultante:

╔═══════════════╦══════════════╦══════════════╦══════════════╗ ║ 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 ║ ╚═══════════════╩══════════════╩══════════════╩══════════════╝

Recomendaría usar core.autocrlf = input en todas las plataformas. En este caso, si Git se enfrenta a CRLF , lo convertirá implícitamente en LF , y los archivos existentes con LF permanecerán como están.

No entiendo las complejidades relacionadas con la configuración de CrLf en git: core.autocrlf , core.safecrlf

Estoy desarrollando un proyecto multiplataforma en un equipo y me gustaría que los desarrolladores de Windows y Linux puedan trabajar juntos sin tener que marcar los archivos modificados solo por el estilo de final de línea.

¿Qué significan las diversas configuraciones? ¿Cuáles serían las consecuencias de elegir cualquiera de las opciones? ¿Y cuál sería la mejor solución para mi caso?

Sí, estoy al tanto de esta pregunta y las respuestas no fueron perspicaces, por lo tanto, no fueron útiles.

FYI., Por defecto, la terminación de línea en Windows tomará CRLF y Linux tomará LF. Por favor encuentre la tabla a continuación para una comprensión clara.

╔═══════════════╦══════════════╦══════════════╦══════════════╗ ║ core.autocrlf ║ false ║ input ║ true ║ ║ ║ Win => Unix ║ Win => Unix ║ Win => Unix ║ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ ║ git commit ║ LF => LF ║ LF => LF ║ LF => LF ║ ║ ║ CR => CR ║ CR => CR ║ CR => CR ║ ║ ║ CRLF => CRLF ║ *CRLF => LF ║ *CRLF => LF ║ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ ║ git checkout ║ LF => LF ║ LF => LF ║ *LF => CRLF ║ ║ ║ CR => CR ║ CR => CR ║ CR => CR ║ ║ ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║ ╚═══════════════╩══════════════╩══════════════╩══════════════╝

En la información tabular anterior, el símbolo * resalta las diferencias entre Windows y Unix. A simple vista, a continuación se muestra la información de CLRF basada en las plataformas del sistema operativo:

Para usuarios de Windows

Si los usuarios de Windows trabajan con proyectos multiplataforma, DEBE ser core.autocrlf=true para máquinas Windows y core.autocrlf=input para máquinas Unix.
Si los usuarios de Windows trabajan solo con proyectos de Windows, puede ser core.autocrlf=true o core.autocrlf=false . Pero core.autocrlf=input generará problemas en este caso.

Para usuarios de Unix (Linux / Mac OS)

Si los usuarios de Unix trabajan con proyectos multiplataforma, DEBE ser core.autocrlf=true para máquinas Windows y core.autocrlf=input para máquinas Unix.
Si los usuarios de Unix trabajan con proyectos Only Unix, puede ser core.autocrlf=input o core.autocrlf=false . Pero core.autocrlf=true dará como resultado problemas en este caso.

Para los mismos usuarios de SO

Para un proyecto puro de Windows o puro Unix, puede ser core.autocrlf=false .

Los tres valores para autocrlf :

true : cuando el contenido entra en el repositorio (se confirma), sus finales de línea se convertirán a LF, y cuando el contenido sale del repositorio (se desprotege), los finales de línea se convierten a CRLF. En general, esto está destinado a usuarios / editores sin experiencia. Dada la suposición de que un editor (o usuario) va a crear archivos con terminaciones CRLF, y se asustará si ve finales de LF normales, pero que quiere finales LF en el repositorio, con suerte lo cubrirá. Sin embargo, es posible que las cosas salgan mal. Hay ejemplos de conflictos de fusión falsos e informes de archivos modificados en las preguntas vinculadas.
input : cuando el contenido entra en el repositorio, sus terminaciones de línea se convertirán a LF, pero el contenido no se tocará en el camino de salida. Esto es básicamente en el mismo campo que true , con la suposición de que los editores en realidad pueden manejar las terminaciones de LF correctamente; solo está protegiendo contra la posibilidad de crear accidentalmente un archivo con terminaciones CRLF.
false - git no trata con terminaciones de línea en absoluto. Tu decides. Esto es lo que mucha gente recomienda. Con esta configuración, si las terminaciones de línea de un archivo van a tener problemas, tendrá que ser consciente de ello, por lo que los conflictos de fusión son mucho menos probables (suponiendo usuarios informados). Educar a los desarrolladores sobre cómo usar sus editores / IDE puede en gran medida resolver el problema. Todos los editores que he visto diseñados para programadores son capaces de manejar esto si están configurados correctamente.

Tenga en cuenta que autocrlf no afectará el contenido que ya está en el repositorio. Si has cometido algo con terminaciones CRLF previamente, se mantendrán de esa manera. Esta es una muy buena razón para evitar depender de autocrlf; si un usuario no lo tiene configurado, puede obtener contenido con terminaciones CRLF en el repositorio, y se mantendrá. Una forma más fuerte de forzar la normalización es con el atributo de texto ; establecerlo en auto para una ruta determinada lo marcará para la normalización al final de la línea, suponiendo que git decida que el contenido es texto (no binario).

Una opción relacionada es safecrlf , que básicamente es solo una forma de asegurarse de no realizar irreversiblemente la conversión CRLF en un archivo binario.

No tengo mucha experiencia lidiando con problemas de Windows y git, así que los comentarios sobre las implicaciones / trampas son ciertamente bienvenidos.