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

Question

J'ai un dépôt Git auquel on accède à la fois depuis Windows et OS X, et je sais que certains fichiers contiennent déjà des fins de ligne CRLF. Pour autant que je sache, il y a deux façons de gérer ce problème :

1. Définir core.autocrlf a false partout,

2. Suivez les instructions aquí (repris dans les pages d'aide de GitHub) pour convertir le référentiel afin qu'il ne contienne que des fins de lignes LF, et ensuite mettre core.autocrlf a true sur Windows et input sur OS X. Le problème, c'est que si j'ai des fichiers binaires dans le référentiel qui.. :

   1. ne sont pas correctement marqués comme binaires dans gitattributes, et
   2. contiennent à 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 pas désactiver la conversion de fin de ligne de Git ? Il y a beaucoup d'avertissements vagues sur le web à propos de l'utilisation de la conversion de fin de ligne. core.autocrlf éteint causant des problèmes, mais très peu spécifique Les seuls que j'ai trouvés jusqu'à présent sont que kdiff3 ne peut pas gérer les fins de 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 ou des exigences de fin de ligne différents.

Existe-t-il d'autres problèmes liés au fait de laisser les fins de ligne telles quelles, dont je ne suis pas conscient ?

Answer 1

Les seules raisons spécifiques de mettre autocrlf a true sont :

• éviter git status montrant tous vos fichiers comme modified en raison de la conversion automatique EOL effectuée lors du clonage d'un repo Git basé sur Unix EOL vers un repo Windows (cf. numéro 83 par exemple)
• et vos outils de codage dépendent en quelque sorte d'un indigène Le style EOL étant présent dans votre fichier :
  • par exemple, un générateur de code codé en dur pour détecter l'EOL native.
  • autres lots externes (externes à votre repo) avec regexp ou code défini pour détecter l'EOL native
  • Je crois que certains plugins Eclipse peuvent produire des fichiers avec des CRLF quelle que soit la plateforme, ce qui peut être un 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é ).

A moins que vous puissiez voir un traitement spécifique qui doit s'occuper de l'EOL native, vous êtes mieux lotis en quittant autocrlf a false ( git config --global core.autocrlf false ).

Notez que cette configuration serait un local un (parce que la configuration n'est pas poussée de repo à repo)

Si vous voulez la même configuration pour tous les utilisateurs qui clonent ce repo, consultez " Quel est le meilleur CRLF stratégie de manipulation avec git ? ", en utilisant le text dans le .gitattributes fichier .

Exemple :

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

---

Remarque : à partir de git 2.8 (mars 2016), les marqueurs de fusion seront les suivants plus du tout introduire une fin de ligne mixte (LF) dans un fichier CRLF.
Voir " Faire en sorte que Git utilise le caractère CRLF sur ses lignes de fusion "<<<<<<< HEAD "

Answer 2

Je suis un développeur .NET et j'utilise Git et Visual Studio depuis des années. Je vous recommande vivement de mettre les fins de lignes à true. Et faites-le le plus tôt possible dans la vie de votre référentiel.

Ceci étant dit, je déteste que Git change mes fins de lignes. Le contrôle de source ne devrait que sauvegarder et récupérer le travail que je fais, il ne devrait PAS le modifier. Jamais. Mais il le fait.

Ce qui se passera si vous n'avez pas tous les développeurs sur vrai, c'est qu'UN développeur finira par mettre sur vrai. Cela commencera à changer les fins de ligne de tous vos fichiers en LF dans votre repo. Et lorsque les utilisateurs réglés sur false les vérifient, Visual Studio vous prévient et vous demande de les modifier. Deux choses vont se produire très rapidement. La première est que vous recevrez de plus en plus de ces avertissements, plus votre équipe est grande, plus vous en recevrez. La deuxième, et la pire, est qu'il montrera que chaque ligne de chaque fichier modifié a été changée (parce que les fins de ligne de chaque ligne seront changées par le vrai gars). Au final, vous ne serez plus en mesure de suivre les modifications de votre dépôt de manière fiable. Il est BEAUCOUP plus facile et plus propre de faire en sorte que tout le monde reste dans le vrai que d'essayer de faire en sorte que tout le monde reste dans le faux. Aussi horrible que ce soit de vivre avec le fait que votre contrôle de source de confiance fait quelque chose qu'il ne devrait pas faire. Jamais.

Answer 3

Mise à jour 2 :

Xcode 9 semble avoir une "fonctionnalité" qui lui permet d'ignorer les fins de ligne actuelles du fichier et d'utiliser le paramètre de fin de ligne par défaut lors de l'insertion de lignes dans un fichier, ce qui donne des fichiers avec des fins de ligne mixtes.

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

Pendant la période où il a existé, ce bogue a provoqué une petite dose d'hilarité dans la base de code à laquelle je fais référence dans la question (qui utilise à ce jour autocrlf=false ), ce qui a conduit à de nombreux messages de livraison "EOL" et finalement à l'écriture d'un fichier git pre-commit crochet pour vérifier/empêcher l'introduction de fins de lignes mixtes.

Mise à jour :

Remarque : comme l'a noté VonC, à partir de Git 2.8, les marqueurs de fusion sera no 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 ajoutées par git pour marquer les différences sont les suivantes no ont des fins de lignes Windows, même si le reste du fichier en a, et vous pouvez vous retrouver avec un fichier avec des fins de lignes 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 de manière sensible les fins de ligne mixtes - en tout cas, tous ceux que nous utilisons le font), mais c'est quelque chose dont il faut être conscient.

L'autre chose * nous avons constaté que lorsque l'on utilise git diff pour visualiser les modifications apportées à un fichier ayant des fins de ligne Windows, les lignes qui ont été ajoutées affichent leur retour chariot, donc :

    // Not changed

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

_{* Ça ne mérite pas vraiment le terme : "problème".}

Answer 4

Pour moi.

Modifier le fichier .gitattributes.

ajouter

*.dll binary

Alors tout va bien.

Answer 5

Je travaille sur GitHub et j'ai trouvé cet article utile.

Il décrit la configuration de git autocrlf et le paramétrage du fichier .gitattributes.