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

J'ai un référentiel Git accessible à partir de Windows et OS X, et que je sais contient déjà certains fichiers avec des fins de ligne CRLF. Autant que je sache, il y a deux façons de gérer cela:

1. Mis core.autocrlfà falsepartout,

2. Suivez les instructions ici (écho sur les pages d'aide GitHub) pour convertir le référentiel pour ne contenir que de fins de ligne LF, et mis ensuite core.autocrlfà truesous Windows et inputsous Mac OS X. Le problème avec cela est que si j'ai des fichiers binaires dans le référentiel cette:

   1. ne sont pas correctement marqués comme binaires dans gitattributes, et
   2. arriver à contenir à la fois CRLF et 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 la core.autocrlfdésactivation causant des problèmes, mais très peu de problèmes spécifiques ; le seul que j'ai trouvé jusqu'à présent est que kdiff3 ne peut pas gérer les terminaisons CRLF (pas un problème pour moi), et que certains éditeurs de texte ont des problèmes de fin de ligne (également pas un problème pour moi).

Le référentiel est interne à mon entreprise et je n'ai donc pas à me soucier de le partager avec des personnes ayant des paramètres d'autocrlf différents ou des exigences de fin de ligne.

Y a-t-il d'autres problèmes avec le fait de laisser les terminaisons de ligne telles quelles que je ne connais pas?

Les raisons que précises dictant autocrlfà truesont:

• évitez d' git statusafficher tous vos fichiers en modifiedraison de la conversion EOL automatique effectuée lors du clonage d'un référentiel EOL Git basé sur Unix vers un fichier Windows (voir le problème 83 par exemple)
• et vos outils de codage dépendent en quelque sorte d'un style EOL natif présent dans votre fichier:
  • par exemple, un générateur de code codé en dur pour détecter la fin de vie native
  • d'autres lots externes (externes à votre référentiel) avec regexp ou jeu de codes pour détecter la fin de vie native
  • Je crois que certains plugins Eclipse peuvent produire des fichiers avec CRLF indépendamment de la plate-forme, ce qui peut être un problème.
  • Vous codez avec Notepad.exe ( sauf si vous utilisez un Windows 10 2018.09+, où le Bloc-notes respecte le caractère EOL détecté ).

À moins que vous ne puissiez voir un traitement spécifique qui doit traiter la fin de vie native, vous feriez mieux de partir autocrlfpourfalse ( git config --global core.autocrlf false).

Notez que cette configuration serait locale (car la configuration 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 CRLFstratégie de gestion avec git? ", En utilisant l' textattribut dans le .gitattributesfichier .

Exemple:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Remarque: à partir de git 2.8 (mars 2016), les marqueurs de fusion n'introduiront plus de fin de ligne mixte (LF) dans un fichier CRLF.
Voir " Faire en sorte que Git utilise CRLF sur ses lignes de fusion" <<<<<<< HEAD " "

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

Cela étant dit, je DÉTESTE que Git change mes fins de ligne. Un contrôle de code source doit uniquement enregistrer et récupérer le travail que je fais, il ne doit 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 finira par être défini sur true. Cela commencera à changer les fins de ligne de tous vos fichiers en LF dans votre référentiel. Et lorsque les utilisateurs définissent de fausses vérifications, Visual Studio vous avertit et vous demande de les modifier. Vous aurez 2 choses très rapidement. Premièrement, vous obtiendrez de plus en plus de ces avertissements, plus votre équipe sera grande, plus vous en aurez. La seconde, et pire, 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 gars). Finalement, vous ne pourrez plus suivre de manière fiable les modifications de votre référentiel. 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 de vivre avec le fait que votre contrôle de source de confiance fait quelque chose qu'il ne devrait pas faire. Déjà.

Mise à jour 2 :

Xcode 9 semble avoir une "fonctionnalité" où il ignorera les fins de ligne actuelles du fichier et utilisera simplement votre paramètre de fin de ligne par défaut lors de l'insertion de lignes dans un fichier, ce qui entraîne des fichiers avec des fins de ligne mixtes.

Je suis presque sûr que ce bogue n'existait pas dans Xcode 7; pas sûr de Xcode 8. La bonne nouvelle est qu'il semble être corrigé dans Xcode 10.

Pour le moment où il existait, ce bug a provoqué une petite hilarité dans la base de code à laquelle je fais référence dans la question (qui à ce jour utilise autocrlf=false), et a conduit à de nombreux messages de validation "EOL" et finalement à mon écriture un pre-commitcrochet git pour vérifier pour / empêcher l'introduction de fins de ligne mixtes.

Mise à jour :

Note: Comme indiqué par VonC, à partir de Git 2.8, les marqueurs de fusion ne pas introduire de fins de ligne de style Unix dans un fichier de type Windows .

Original :

Un petit hoquet que j'ai remarqué avec cette configuration est que lorsqu'il y a des conflits de fusion, les lignes que git ajoute pour marquer les différences n'ont pas de fins de ligne Windows, même lorsque le reste du fichier en a, et vous pouvez finir avec un fichier avec des fins de ligne mixtes, 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 toutes celles que nous utilisons), mais c'est quelque chose dont il faut être conscient.

L'autre chose ^{* que} nous avons trouvée, c'est que lors de l'utilisation git diffpour afficher les modifications d'un fichier qui a des fins de ligne Windows, les lignes qui ont été ajoutées affichent leurs retours chariot, ainsi:

    // Not changed

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

_{* Il ne mérite pas vraiment le terme: "issue".}