web-dev-qa-db-fra.com

Pourquoi devrais-je utiliser core.autocrlf = true dans Git?

J'ai un référentiel Git auquel on a accès à partir de Windows et OS X et qui, je le sais, contient déjà des fichiers avec des fins de ligne CRLF. Autant que je sache, il y a deux façons de régler ce problème:

  1. Réglez core.autocrlf sur false partout,

  2. Suivez les instructions ici (sur les pages d'aide de GitHub) pour convertir le référentiel afin qu'il ne contienne que des fins de ligne LF, puis définissez core.autocrlf en true sous Windows et input sous OS X. Le problème, c'est que si j'ai des fichiers binaires dans le référentiel:

    1. ne sont pas correctement marqués comme binaires dans gitattributes, et
    2. arriver à contenir à la fois des CRLF et des LF,

    ils seront corrompus. Il est possible que mon référentiel contienne de tels fichiers.

Alors pourquoi ne devrais-je pas simplement désactiver la conversion de fin de ligne de Git? Il existe de nombreux avertissements vagues sur le Web concernant le fait que core.autocrlf soit désactivé, ce qui cause des problèmes, mais très peu spécifiques ; La seule chose que j'ai trouvée jusqu'à présent est que kdiff3 ne peut pas gérer les fins du CRLF (ce n'est pas un problème pour moi) et que certains éditeurs de texte ont des problèmes de fin de ligne (ce n'est pas non plus un problème pour moi).

Le référentiel est interne à mon entreprise. Par conséquent, je n'ai pas à craindre de le partager avec des personnes ayant des paramètres d'autocrlf ou des exigences de fin de ligne différents.

Y a-t-il d'autres problèmes à laisser simplement des fins de lignes comme je ne suis pas au courant?

gitline-endings
262
Rich

Les seules raisons spécifiques pour définir autocrlf sur true sont les suivantes:

  • éviter _git status_ d'afficher tous vos fichiers sous la forme modified en raison de la conversion EOL automatique effectuée lors du clonage d'un dépôt EOL Git basé sur Unix sur un support Windows (voir numéro 8 , par exemple)
  • and vos outils de codage dépendent d’une manière ou d’une autre du style natif EOL présent dans votre fichier:
    • par exemple, un générateur de code codé en dur pour détecter la fin de vie native
    • autres lots externes (externes à votre référentiel) avec regexp ou code défini pour détecter la fin de vie native
    • Je crois que certains plug-ins Eclipse peuvent produire des fichiers avec CRLF indépendamment de la plate-forme, ce qui peut poser problème.
    • Vous codez avec Notepad.exe ( sauf si vous utilisez un Windows 10 2018.09+, où Notepad respecte le caractère EOL détecté ).

À moins que vous ne voyiez un traitement spécifique qui doit ​​traiter avec les EOL natifs, vous êtes mieux lotis laissant autocrlf à false .

Notez que cette configuration serait une locale (car elle n'est pas poussée de repo à repo)

Si vous voulez la même configuration pour tous les utilisateurs clonant ce référentiel, consultez " Quelle est la meilleure stratégie de traitement de CRLF avec git? ", à l'aide de l'attribut text dans le fichier .gitattributes == .

Remarque: à partir de git 2.8 (mars 2016), les marqueurs de fusion introduiront plus maintenant ​​l'introduction d'une fin de ligne mixte (LF) dans un fichier CRLF.
Voir " Amener Git à utiliser CRLF sur ses lignes de fusion" <<<<<<< HEAD " "

194
VonC

Je suis un développeur .NET et utilise Git et Visual Studio depuis des années. Ma forte recommandation est de définir les fins de ligne sur true. Et faites-le le plus tôt possible dans la vie de votre référentiel.

Cela étant dit, je déteste que Git change les fins de ligne. Un contrôle de source ne devrait enregistrer et récupérer que le travail que je fais, il ne devrait pas le modifier. Déjà. Mais c'est le cas.

Que se passera-t-il si tous les développeurs ne sont pas définis sur true, si UN développeur finit par définir sur true. Cela commencera à changer les fins de ligne de tous vos fichiers en LF dans votre référentiel. Et lorsque les utilisateurs sont définis sur false, vérifiez que celles-ci sont vérifiées, Visual Studio vous en avertit et vous demande de les modifier. Vous aurez 2 choses arriver très vite. Premièrement, vous recevrez de plus en plus de ces avertissements, plus votre équipe sera grande, plus vous en obtiendrez. La deuxième, et pire chose, est que cela montrera que chaque ligne de chaque fichier modifié a été modifiée (car les fins de ligne de chaque ligne seront modifiées par le vrai interlocuteur). En fin de compte, vous ne pourrez plus suivre les modifications de votre repo de manière fiable. Il est BEAUCOUP plus facile et plus propre de faire en sorte que tout le monde reste fidèle, que d'essayer de garder tout le monde faux. Aussi horrible que cela soit de vivre avec le fait que votre contrôle de code source fiable fait quelque chose qu'il ne devrait pas faire. Déjà.

30
JGTaylor

Mise à jour :

Remarque: Comme l'a noté VonC, à partir de Git 2.8, fusionnent les marqueurs sera pas introduire des fins de ligne de style Unix dans un fichier de style Windows .

Original :

Un petit problème que j'ai remarqué avec cette configuration est que lorsqu'il y a des conflits de fusion, les lignes git s'ajoutent pour marquer les différences ne pas ont des fins de lignes Windows, même lorsque le reste du fichier existe, et vous pouvez vous retrouver avec un fichier avec des fins de ligne mélangées, par exemple:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Cela ne nous pose aucun problème (j'imagine que tout outil capable de gérer les deux types de fins de ligne traitera également les fins de ligne mixtes - certainement de celles que nous utilisons), mais il faut en être conscient.

L'autre chose* Nous avons constaté que lorsque vous utilisez git diff pour afficher les modifications apportées à un fichier comportant des fins de ligne Windows, les lignes ajoutées affichent leurs retours à la ligne, par exemple:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

* Cela ne mérite pas vraiment le terme: "problème".

12
Rich