usuario password guardar credenciales cambiar borrar and git newline core.autocrlf

password - Cómo funcionan las conversiones de finalización de línea con git core.autocrlf entre diferentes sistemas operativos



git config--global (7)

He leído muchas preguntas y respuestas diferentes sobre Stack Overflow, así como documentación de git sobre cómo funciona la configuración core.autocrlf .

Este es mi entendimiento de lo que he leído:

Los clientes de Unix y Mac OSX (antes de OSX usa CR) usan terminaciones de línea LF.
Los clientes de Windows usan terminaciones de línea CRLF.

Cuando core.autocrlf se establece en true en el cliente, el repositorio de git siempre almacena los archivos en formato de fin de línea LF y los finales de línea en los archivos en el cliente se convierten una y otra vez en checkout / commit para clientes (es decir, Windows) que utilizan -LF terminaciones de línea, sin importar qué formato tengan los archivos de finalización de línea en el cliente (esto no está de acuerdo con la definición de Tim Clem; consulte la actualización a continuación).

Aquí hay una matriz que intenta documentar lo mismo para la configuración de ''entrada'' y ''falsa'' de core.autocrlf con signos de interrogación en los que no estoy seguro del comportamiento de conversión de terminación de línea.

Mis preguntas son:

  1. ¿Cuáles deberían ser los signos de interrogación?
  2. ¿Es esta matriz correcta para los "signos de no interrogación"?

Actualizaré los signos de interrogación de las respuestas ya que parece haber consenso.

core.autocrlf value true input false ---------------------------------------------------------- commit | convert ? ? new | to LF (convert to LF?) (no conversion?) commit | convert to ? no existing | LF (convert to LF?) conversion checkout | convert to ? no existing | CRLF (no conversion?) conversion

Realmente no estoy buscando opiniones sobre los pros y los contras de las diversas configuraciones. Solo busco información que aclare cómo esperar que git opere con cada una de las tres configuraciones.

-

Actualización 17/04/2012 : Después de leer el artículo de Tim Clem vinculado por JJD en los comentarios, modifiqué algunos de los valores en los valores "desconocidos" en la tabla anterior, y también cambié "checkout existing | true to convert" a CRLF en lugar de convertir al cliente ". Aquí están las definiciones que él da, que son más claras que cualquier otra cosa que haya visto en otra parte:

core.autocrlf = falso

Este es el valor predeterminado, pero se recomienda a la mayoría de las personas que lo cambien de inmediato. El resultado de usar false es que Git nunca se mete con los finales de línea en su archivo. Puede verificar los archivos con LF, CRLF o CR o una combinación aleatoria de esos tres y a Git no le importa. Esto puede dificultar la lectura de las dificultades y se funde más. La mayoría de las personas que trabajan en un mundo Unix / Linux usan este valor porque no tienen problemas CRLF y no necesitan que Git haga un trabajo extra cada vez que los archivos se escriben en la base de datos de objetos o se escriben en el directorio de trabajo.

core.autocrlf = true

Esto significa que Git procesará todos los archivos de texto y se asegurará de que CRLF se sustituya por LF cuando escriba ese archivo en la base de datos de objetos y vuelva a convertir todo LF en CRLF cuando escriba en el directorio de trabajo. Esta es la configuración recomendada en Windows porque garantiza que su repositorio se pueda usar en otras plataformas al tiempo que conserva CRLF en su directorio de trabajo.

core.autocrlf = entrada

Esto significa que Git procesará todos los archivos de texto y se asegurará de que CRLF se sustituya por LF al escribir ese archivo en la base de datos de objetos. Sin embargo, no hará lo contrario. Cuando vuelva a leer archivos de la base de datos de objetos y los escriba en el directorio de trabajo, seguirán teniendo LF para indicar el final de la línea. Esta configuración generalmente se usa en Unix / Linux / OS X para evitar que los CRLF se escriban en el repositorio. La idea era que si pegaba código desde un navegador web y accidentalmente obtenía CRLF en uno de sus archivos, Git se aseguraría de que se reemplazaran con LF cuando escribiera en la base de datos de objetos.

El artículo de Tim es excelente, lo único que se me ocurre que falta es que asume que el repositorio está en formato LF, lo que no es necesariamente cierto, especialmente para proyectos solo de Windows.

Comparar el artículo de Tim con la respuesta más votada hasta la fecha por jmlane muestra un acuerdo perfecto sobre la configuración verdadera y de entrada y el desacuerdo sobre la configuración falsa.

Aquí está mi entendimiento de eso hasta ahora, en caso de que ayude a alguien.

core.autocrlf=true y core.safecrlf = true

Tienes un repositorio donde todas las terminaciones de línea son iguales , pero trabajas en diferentes plataformas. Git se asegurará de que las terminaciones de tus líneas se conviertan a las predeterminadas para tu plataforma. ¿Por qué importa esto? Digamos que creas un nuevo archivo. El editor de texto en su plataforma usará sus finales de línea predeterminados. Cuando lo registra, si no tiene core.autocrlf configurado en verdadero, ha introducido una inconsistencia de finalización de línea para alguien en una plataforma que por defecto tiene una terminación de línea diferente. Siempre configuro safecrlf porque me gustaría saber que la operación crlf es reversible. Con estas dos configuraciones, git está modificando sus archivos, pero verifica que las modificaciones sean reversibles .

core.autocrlf=false

Tiene un repositorio que ya tiene las terminaciones de línea mixtas registradas y corregir las terminaciones de línea incorrectas podría romper otras cosas. Es mejor no decirle a git que convierta las terminaciones de línea en este caso, porque de ese modo empeorará el problema para el que fue diseñado, haciendo que las lecturas sean más fáciles de leer y las que se fundan menos dolorosas. Con esta configuración, git no modifica tus archivos .

core.autocrlf=input

No uso esto porque la razón para esto es para cubrir un caso de uso donde creó un archivo que tiene terminaciones de línea CRLF en una plataforma que por defecto tiene terminaciones de línea LF. Prefiero en cambio hacer que mi editor de texto siempre guarde nuevos archivos con los valores predeterminados de final de línea de la plataforma.

El problema de los EOL en proyectos de plataforma mixta ha estado haciendo que mi vida sea miserable durante mucho tiempo. Los problemas generalmente surgen cuando ya hay archivos con EOL diferentes y mixtos en el repositorio. Esto significa que:

  1. El repositorio puede tener diferentes archivos con diferentes EOL
  2. Algunos archivos en el repositorio pueden tener EOL mixto, por ejemplo, una combinación de CRLF y LF en el mismo archivo.

Cómo sucede esto no es el problema aquí, pero sucede.

Realicé algunas pruebas de conversión en Windows para los distintos modos y sus combinaciones.
Esto es lo que obtuve, en una tabla ligeramente modificada:

| 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

Como puede ver, hay 2 casos en que la conversión ocurre en la confirmación (3 columnas a la izquierda). En el resto de los casos, los archivos se confirman tal como están.

Al momento del pago (3 columnas a la derecha), solo hay 1 caso donde la conversión ocurre cuando:

  1. core.autocrlf es true y
  2. el archivo en el repositorio tiene LF EOL.

Lo más sorprendente para mí, y sospecho, la causa de muchos problemas de EOL es que no hay ninguna configuración en la que la EOL mixta como CRLF + LF se normalice.

Tenga en cuenta también que los EOL "antiguos" de CR de Mac solo nunca se convierten.
Esto significa que si un script de conversión EOL mal escrito intenta convertir un archivo final mixto con CRLF s + LF s, simplemente convirtiendo LF s en CRLF s, entonces dejará el archivo en un modo mixto con CR "solitarias" siempre que CRLF se convirtió a CRCRLF .
Git no convertirá nada, ni siquiera en modo true , y los estragos de EOL continuarán. En realidad, esto me sucedió y estropeó mis archivos realmente mal, ya que a algunos editores y compiladores (por ejemplo, VS2010) no les gustan los EOL de Mac.

Supongo que la única forma de manejar realmente estos problemas es ocasionalmente normalizar todo el repositorio comprobando todos los archivos en modo de input o false , ejecutando una normalización adecuada y volviendo a confirmar los archivos modificados (si corresponde). En Windows, presumiblemente se reanuda el trabajo con core.autocrlf true .

Hice algunas pruebas tanto en Linux como en Windows. Utilizo un archivo de prueba que contiene líneas que terminan en LF y también líneas que terminan en CRLF.
El archivo se confirma, elimina y luego se retira. El valor de core.autocrlf se establece antes de la confirmación y también antes de finalizar la compra. El resultado está abajo.

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF CRLF=>CRLF commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF CRLF=>CRLF commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF CRLF=>CRLF commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF CRLF=>LF commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF CRLF=>LF commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF CRLF=>LF commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF CRLF=>LF commit core.autocrlf true, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF

La mejor explicación de cómo funciona core.autocrlf se encuentra en la página de manual de gitattributes , en la sección de atributo de text .

Así es como core.autocrlf parece funcionar actualmente (o al menos desde v1.7.2 por lo que yo sé):

  • core.autocrlf = true
    1. Los archivos de texto extraídos del repositorio que solo tienen caracteres LF están normalizados a CRLF en su árbol de trabajo; los archivos que contienen CRLF en el repositorio no se tocarán
    2. Los archivos de texto que tienen solo caracteres LF en el repositorio, se normalizan de CRLF a LF cuando se confirman en el repositorio. Los archivos que contienen CRLF en el repositorio se comprometerán intactos.
  • core.autocrlf = input
    1. Los archivos de texto prestados del repositorio mantendrán caracteres EOL originales en su árbol de trabajo.
    2. Los archivos de texto en su árbol de trabajo con caracteres CRLF se normalizan en LF cuando se los vuelve a enviar al repositorio.
  • core.autocrlf = false
    1. core.eol dicta caracteres EOL en los archivos de texto de su árbol de trabajo.
    2. core.eol = native de forma predeterminada, lo que significa que los EOL de Windows son CRLF y * nix EOL son LF en árboles activos.
    3. gitattributes configuración de repositorios de gitattributes determina la normalización de caracteres EOL para confirmaciones en el repositorio (la normalización predeterminada es en caracteres LF ).

Recientemente investigué este problema y también encuentro que la situación es complicada. La configuración core.eol definitivamente ayudó a aclarar cómo Git maneja los caracteres EOL.

Las cosas están a punto de cambiar en el frente de la "conversión eol", con el próximo Git 1.7.2 :

Se está agregando / evolucionando una nueva configuración config core.eol :

Este es un reemplazo para la core.eol ''Agregar'' core.eol ''variable de configuración'' que está actualmente en pu (la última en mi serie).
En lugar de implicar que " core.autocrlf=true " es un reemplazo para " * text=auto ", hace explícito el hecho de que autocrlf es solo para usuarios que desean trabajar con CRLF en su directorio de trabajo en un repositorio que no funciona tener la normalización del archivo de texto .
Cuando está habilitado, se ignora "core.eol".

Introduzca una nueva variable de configuración, " core.eol ", que le permite al usuario establecer qué terminaciones de línea usar para los archivos normalizados al final de la línea en el directorio de trabajo.
Por defecto es " native ", lo que significa CRLF en Windows y LF en cualquier otro lado. Tenga en cuenta que " core.autocrlf " anula core.eol .
Esto significa que:

[core] autocrlf = true

pone los CRLF en el directorio de trabajo incluso si core.eol está establecido en " lf ".

core.eol:

Establece el tipo de terminación de línea para usar en el directorio de trabajo para los archivos que tienen establecida la propiedad de text .
Las alternativas son ''lf'', ''crlf'' y ''native'', que usa la terminación de línea nativa de la plataforma.
El valor predeterminado es native .

Se están considerando otras evoluciones:

Para 1.8, consideraría hacer que core.autocrlf simplemente active la normalización y deje la línea de directorio de trabajo terminando la decisión a core.eol, pero eso romperá las configuraciones de las personas.

git 2.8 (marzo de 2016) mejora la forma en que core.autocrlf influye en el eol:

Consulte commit 817a0c7 (23 de febrero de 2016), commit 6e336a5 , commit df747b8 , commit df747b8 (10 de febrero de 2016), commit df747b8 , commit df747b8 (10 de febrero de 2016), y commit 4b4024f , commit bb211b4 , commit 92cce13 , commit 320d39c , commit 4b4024f , commit bb211b4 , commit 92cce13 , commit 320d39c (05 Feb 2016) por Torsten Bögershausen ( tboegi ) .
(Fusionado por Junio ​​C Hamano - gitster - in commit c6b94eb , 26 de febrero de 2016)

convert.c : refactor crlf_action

Refactorizar la determinación y el uso de crlf_action .
Hoy, cuando no se establece ningún atributo " crlf " en un archivo, crlf_action se establece en CRLF_GUESS . Use CRLF_UNDEFINED en CRLF_UNDEFINED lugar, y busque " text " o " eol " como antes.

Reemplace el viejo uso de CRLF_GUESS :

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

Haga más claro, qué es qué, definiendo:

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf and core.eol is evaluated and one of CRLF_BINARY, CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected - CRLF_BINARY : No processing of line endings. - CRLF_TEXT : attribute "text" is set, line endings are processed. - CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text. - CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text. - CRLF_AUTO : attribute "auto" is set. - CRLF_AUTO_INPUT: core.autocrlf=input (no attributes) - CRLF_AUTO_CRLF : core.autocrlf=true (no attributes)

Como agrega torek en los comentarios :

todas estas traducciones (cualquier conversión EOL de eol= o configuración autocrlf , y filtros " clean ") se ejecutan cuando los archivos se mueven de árbol de trabajo a índice , es decir, durante git add y no en git commit time.
( --only --include , --include cuenta que git commit -a o --only --include agregan archivos al índice en ese momento).

Para obtener más información al respecto, consulte " ¿Cuál es la diferencia entre autocrlf y eol ".

No, la respuesta de @jmlane es incorrecta.

Para Checkin (git add, git commit) :

  1. si la propiedad del text es Set, Set value to ''auto'' , la conversión ocurre cuando el archivo se ha confirmado con ''CRLF''
  2. si la propiedad del text es Unset : no pasa nada, enen para Checkout
  3. si la propiedad de text Unspecified está Unspecified , la conversión depende de core.autocrlf
    1. si autocrlf = input or autocrlf = true , la conversión solo ocurre cuando el archivo en el repositorio es ''LF'', si ha sido ''CRLF'', no pasará nada.
    2. si autocrlf = false , no pasa nada

Para el Checkout :

  1. si la propiedad del text es Unset : no pasa nada.
  2. si la propiedad del text es Set, Set value to ''auto core.autocrlf el Set, Set value to ''auto : depende de core.autocrlf , core.eol .
    1. core.autocrlf = input: no pasa nada
    2. core.autocrlf = true: la conversión solo ocurre cuando el archivo en el repositorio es ''LF'', ''LF'' -> ''CRLF''
    3. core.autocrlf = false: la conversión solo ocurre cuando el archivo en el repositorio es ''LF'', ''LF'' -> core.eol
  3. si la propiedad de text Unspecified está Unspecified , depende de core.autocrlf .
    1. lo mismo que 2.1
    2. lo mismo que 2.2
    3. Ninguno, no ocurre nada, core.eol no es efectivo cuando la propiedad de text Unspecified está Unspecified

Comportamiento por defecto

Por lo tanto, el comportamiento predeterminado es la propiedad de text Unspecified y core.autocrlf = false :

  1. para registrarse, no pasa nada
  2. para el pago, no pasa nada

Conclusiones

  1. si se establece la propiedad de text , el comportamiento de control depende de sí mismo, no de autocrlf
  2. autocrlf o core.eol es para el comportamiento de pago y autocrlf> core.eol

core.autocrlf valor de core.autocrlf no depende del tipo de SO, pero el valor predeterminado de Windows es true y para Linux - input . 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 ║ ╚═══════════════╩══════════════╩══════════════╩══════════════╝