web-dev-qa-db-fra.com

Git sous Windows: que signifient les paramètres crlf?

Je ne comprends pas les complexités liées aux paramètres CrLf dans git: core.autocrlf, core.safecrlf

Je développe un projet multiplateforme dans une équipe et j'aimerais que les développeurs Windows et Linux puissent travailler ensemble sans git marquer les fichiers comme modifiés juste à cause du style de fin de ligne.

Que signifient les différents paramètres? Quelles seraient les conséquences du choix de l'une des options? Et quelle serait la meilleure solution pour mon cas?

Oui, je suis au courant de cette question et les réponses n'étaient pas pertinentes, donc pas utiles.

windowslinuxgitnewlinecore.autocrlf
71
Jonathan

Les trois valeurs de autocrlf:

  • true - lorsque le contenu entre dans le référentiel (est validé), ses fins de ligne sont converties en LF, et lorsque le contenu sort du référentiel (est extrait), les fins de ligne sont converties en CRLF. Ceci est généralement destiné aux utilisateurs/éditeurs Windows désemparés. Étant donné l'hypothèse qu'un éditeur (ou un utilisateur) va créer des fichiers avec des terminaisons CRLF et paniquera s'il voit des terminaisons normales LF, mais que vous voulez LF terminaisons dans le référentiel, cela vous couvrira, espérons-le. Il est possible que les choses tournent mal, cependant. Il y a des exemples de conflits de fusion parasites et des rapports de fichiers modifiés dans les questions liées.

  • input - lorsque le contenu va dans le référentiel, ses fins de ligne seront converties en LF, mais le contenu reste intact à la sortie. Ceci est essentiellement dans le même domaine que true, avec l'hypothèse que les éditeurs peuvent réellement traiter LF terminaisons correctement; vous vous gardez juste contre la possibilité de créer accidentellement un fichier avec terminaisons CRLF.

  • false - git ne gère pas du tout les fins de ligne. C'est à vous. C'est ce que beaucoup de gens recommandent. Avec ce paramètre, si les fins de ligne d'un fichier vont être gâchées, vous devrez en être conscient, donc les conflits de fusion sont beaucoup moins probables (en supposant des utilisateurs informés). L'éducation des développeurs sur la façon d'utiliser leurs éditeurs/IDE peut à peu près résoudre le problème. Tous les éditeurs que j'ai vus conçus pour les programmeurs sont capables de gérer cela s'ils sont correctement configurés.

Notez que autocrlf n'affectera pas le contenu qui est déjà dans le référentiel. Si vous avez déjà commis quelque chose avec des terminaisons CRLF, elles le resteront. C'est une très bonne raison d'éviter de dépendre de autocrlf; si un utilisateur ne l'a pas défini, il peut obtenir du contenu avec des terminaisons CRLF dans le référentiel, et cela restera. Un moyen plus puissant de forcer la normalisation consiste à utiliser attribut text ; le définir sur auto pour un chemin donné le marquera pour la normalisation de fin de ligne, en supposant que git décide que le contenu est du texte (pas binaire).

Une option connexe est safecrlf, qui est fondamentalement juste un moyen de s'assurer que vous n'effectuez pas de manière irréversible la conversion CRLF sur un fichier binaire.

Je n'ai pas une tonne d'expérience dans le traitement des problèmes Windows et Git, donc les commentaires sur les implications/pièges sont certainement les bienvenus.

94
Cascabel

J'ai exploré 3 valeurs possibles pour les cas de validation et d'extraction et voici le tableau résultant:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   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 ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Je recommanderais d'utiliser core.autocrlf = input sur toutes les plateformes. Dans ce cas, si Git fait face à CRLF, il le convertira implicitement en LF, et les fichiers existants avec LF resteront tels quels.

9
pratt

FYI., Par défaut, la ligne se terminant par Windows prendra CRLF et Linux prendra LF. Veuillez trouver le tableau ci-dessous pour une compréhension claire.

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

Dans les informations tabulaires ci-dessus, le symbole * met en évidence les différences entre Windows et Unix. En bref, voici les informations CLRF basées sur les plates-formes OS:

Pour les utilisateurs de Windows

  • Si les utilisateurs de Windows travaillent avec des projets multiplateformes, il DOIT être core.autocrlf=true pour les machines Windows et core.autocrlf=input pour les machines Unix.
  • Si les utilisateurs de Windows travaillent uniquement avec des projets Windows, cela peut être à la fois core.autocrlf=true ou core.autocrlf=false. Mais core.autocrlf=input entraînera des problèmes dans ce cas.

Pour les utilisateurs Unix (Linux/Mac OS)

  • Si les utilisateurs Unix travaillent avec des projets multiplateformes, il DOIT être core.autocrlf=true pour les machines Windows et core.autocrlf=input pour les machines Unix.
  • Si les utilisateurs Unix travaillent uniquement avec des projets Unix, cela peut être à la fois core.autocrlf=input ou core.autocrlf=false. Mais core.autocrlf=true entraînera des problèmes dans ce cas.

Pour les mêmes utilisateurs d'OS

  • Pour un projet Windows pur ou un projet Unix pur, il peut être core.autocrlf=false.
3
Srikanth Popuri