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

j'ai un dépôt Git auquel on accède depuis Windows et OS X, et qui contient déjà des fichiers avec des fins de ligne CRLF. Pour autant que je sache, il y a deux façons de traiter cela:

  1. Set core.autocrlf à false partout", 151970920"

  2. suivez les instructions ici (repris sur les pages d'aide de GitHub) pour convertir le dépôt pour ne contenir que LF le problème est que si j'ai des fichiers binaires dans le dépôt qui:

    1. ne sont pas correctement marqués comme binaires dans gitattributes, et
    2. contain to both CRLFs and LFs,

    ils seront corrompus. Il est possible que mon dépôt contienne de tels fichiers.

alors pourquoi ne devrais-je pas arrêter la conversion de fin de ligne de Git? Il y a beaucoup de vagues avertissements sur le web sur le fait que core.autocrlf est éteint, ce qui cause des problèmes, mais très peu de spécifiques ; les seuls que j'ai trouvé jusqu'à présent sont 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 dépôt est interne à mon entreprise, et donc je n'ai pas besoin de m'inquiéter de le partager avec des gens avec des paramètres autocrlf différents ou des exigences de fin de ligne.

est-ce qu'il y a d'autres problèmes avec le fait de quitter la ligne-terminaisons as-Est-ce que je ne suis pas au courant?

234
demandé sur Community 2010-05-13 12:50:11

3 réponses

les seules raisons spécifiques pour fixer autocrlf à true sont:

  • éviter git status montrant tous vos fichiers comme modified en raison de la conversion automatique de fin de vie effectuée lors du clonage D'un repo de fin de vie basé sur Unix à un Windows one (voir numéro 83 par exemple)
  • et vos outils de codage dépend en quelque sorte un native EOL-style présents dans votre fichier:
    • par exemple, un générateur de code à code dur codé pour détecter la fin de vie native
    • autres lots externes (externes à votre repo) avec regexp ou code réglé pour détecter la fin de vie native
    • je crois que certains plugins Eclipse peuvent produire des fichiers avec CRLF indépendamment sur la plate-forme, ce qui peut être un problème.

sauf si vous pouvez voir un traitement spécifique qui doit traiter avec EOL natif, vous êtes mieux lotis laissant autocrlf à false .

notez que cette config serait une locale (parce que la config n'est pas poussée de repo à repo)

si vous voulez la même configuration pour tous les utilisateurs clonant que repo, consultez " Quelle est la meilleure CRLF stratégie de manipulation avec git? ", en utilisant le text attribut dans le .gitattributes dossier .

Note: à partir de git 2.8 (mars 2016), les marqueurs de fusion vont et non plus introduire la fin de ligne mixte (LF) dans un fichier CRLF.

Voir " Faire Git utilisation CRLF sur son "<<<<<<< TÊTE de" fusionner les lignes "

175
répondu VonC 2017-05-23 12:34:27

je suis un développeur.net, et j'utilise Git et Visual Studio depuis des années. Je recommande fortement que la ligne se termine par true. Et faites-le le plus tôt possible dans la vie de votre dépôt.

cela dit, je déteste que Git change mes fins de ligne. Un contrôle source ne doit sauvegarder et récupérer que le travail que je fais, il ne doit pas le modifier. Jamais. Mais il le fait.

ce qui va se passer si vous n'avez pas tous les développeurs mis à true, est un le développeur finira par mettre à true. Cela commencera à changer les fins de ligne de tous vos fichiers en LF dans votre repo. Et lorsque les utilisateurs défini à false vérifier ces, Visual Studio vous avertira et vous demander de les modifier. Vous aurez 2 choses qui arrivent très rapidement. Un, vous obtiendrez de plus en plus de ces avertissements, plus grande votre équipe, plus vous obtenez. Le deuxième, et le pire, est qu'il va montrer que chaque ligne de chaque fichier modifié a été changé(parce que les fins de ligne de chaque ligne sera changé par le vrai mec). Finalement, vous ne serez plus en mesure de suivre les changements dans votre dossier de pension de façon 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 puisse être de vivre avec le fait que votre source de contrôle fiable fait quelque chose qu'il ne devrait pas faire. Jamais.

20
répondu JGTaylor 2016-06-10 13:23:32

mise à Jour :

Note: Comme noté par VonC, à partir de Git 2.8, fusionner les marqueurs will not introduire des terminaisons de ligne de style Unix dans un fichier de style Windows .

Original :

un petit hoquet que j'ai remarqué avec cette configuration est que lorsqu'il y a des conflits de fusion, les lignes git ajoute pour marquer les différences font pas ont Windows de ligne de fin, même quand le reste du fichier, et vous pouvez vous retrouver avec un fichier avec un mélange de fins de ligne, 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 cause aucun problème (j'imagine qu'un outil capable de gérer les deux types de terminaisons de ligne sera également sensible avec des terminaisons de ligne mélangées--certainement tous ceux que nous utilisons le font), mais c'est quelque chose dont nous devons être conscients.

L'autre chose * nous avons trouvé, c'est que lors de l'utilisation de git diff pour afficher les modifications apportées à un fichier qui a Windows ligne-fin, des lignes qui ont été ajoutés à l'affichage de leurs retours chariot, ainsi: 

    // Not changed

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

* Il n'a pas vraiment de mérite, le terme: "la question".

12
répondu Rich 2017-05-23 12:26:09