git remplaçant LF par CRLF


840

Exécuter git sur une machine Windows XP, en utilisant bash. J'ai exporté mon projet depuis SVN, puis cloné un référentiel nu.

J'ai ensuite collé l'exportation dans le répertoire des référentiels nus et j'ai fait:

git add -A

J'ai ensuite reçu une liste de messages disant:

LF sera remplacé par CRLF

Quelles sont les ramifications de cette conversion? Il s'agit d'une solution .NET dans Visual Studio.


14
@apphacker parce que la standardisation des fins de ligne est moins ennuyeuse que d'avoir à les changer vous-même lorsque vous différez deux fichiers. (Et bien sûr, si vous n'êtes pas d'accord, vous pouvez désactiver la fonction core.autocrlf).
RJFalconer

2
pourquoi les fins de ligne seraient-elles différentes à moins que la ligne entière ne soit touchée
Bjorn

3
Je touche souvent beaucoup de lignes, car j'expérimente avec différentes idées, j'ajoute des instructions de trace pour voir comment elles fonctionnent, etc. les avait remis en place comme je les ai trouvés (du moins je le pensais).
MatrixFrog

5
@MatrixFrog: votre éditeur semble cassé, incapable de détecter automatiquement les fins de ligne. Lequel est-ce? Je travaille sur des projets hybrides qui doivent avoir des fichiers LF et d'autres fichiers CRLF dans le même repo. Pas un problème pour un éditeur moderne. Avoir le contrôle de la version (ou le transfert de fichiers) avec les fins de ligne pour contourner les limitations de l'éditeur est la pire idée qui soit - évident d'après la simple longueur des explications ci-dessous.
MarcH

4
Le seul éditeur moderne que je connaisse qui fait la mauvaise chose est Visual Studio. Visual Studio ouvrira avec plaisir un fichier avec des fins de ligne LF. Si vous insérez ensuite de nouvelles lignes, il insérera CRLF et enregistrera les fins de ligne mixtes. Microsoft refuse de corriger cela, ce qui est un gros défaut sur un IDE par ailleurs assez bon: - (
Jon Watte

Réponses:


958

Ces messages sont dus à une valeur par défaut incorrecte de core.autocrlfsous Windows.

Le concept de autocrlfest de gérer les conversions de fin de ligne de manière transparente. Et c'est le cas!

Mauvaise nouvelle : la valeur doit être configurée manuellement.
Bonne nouvelle : cela ne devrait être fait qu'une seule fois par installation git (par paramètre de projet est également possible).

Comment ça autocrlfmarche :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Ici crlf= marqueur de fin de ligne de style gagnant, lf= style unix (et mac osx).

(pré-osx crn'est pas affecté pour l'une des trois options ci-dessus)

Quand cet avertissement apparaît-il (sous Windows)

    - autocrlf= truesi vous avez un style unix lfdans l'un de vos fichiers (= RAREMENT),
    - autocrlf= inputsi vous avez un style win crlfdans l'un de vos fichiers (= presque TOUJOURS),
    - autocrlf= false- JAMAIS!

Que signifie cet avertissement

L'avertissement " LF sera remplacé par CRLF " indique que vous (ayant autocrlf= true) perdrez votre LF de style Unix après le cycle de validation de validation (il sera remplacé par CRLF de style Windows). Git ne s'attend pas à ce que vous utilisiez le LF de style Unix sous Windows.

L'avertissement " CRLF sera remplacé par LF " indique que vous (ayant autocrlf= input) perdrez votre CRLF de style Windows après un cycle de validation de validation (il sera remplacé par LF de style Unix). Ne pas utiliser inputsous les fenêtres.

Encore une autre façon de montrer comment ça autocrlfmarche

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

x est CRLF (style Windows) ou LF (style Unix) et les flèches représentent

file to commit -> repository -> checked out file

Comment réparer

La valeur par défaut pour core.autocrlfest sélectionnée lors de l'installation de git et stockée dans gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) à l' échelle du système . Il y a aussi (en cascade dans l'ordre suivant):

   - gitconfig "global" (par utilisateur) situé à ~/.gitconfig, encore un autre
   - gitconfig "global" (par utilisateur) à $XDG_CONFIG_HOME/git/configou $HOME/.config/git/configet
   - gitconfig "local" (par repo) à .git/configdans le répertoire de travail.

Donc, écrivez git config core.autocrlfdans le répertoire de travail pour vérifier la valeur actuellement utilisée et

   - ajouter autocrlf=falseà l'ensemble du système gitconfig # solution par système
   - git config --global core.autocrlf false            # solution par utilisateur
   - git config --local core.autocrlf false              # solution par projet

Avertissements
- les git configparamètres peuvent être remplacés par les gitattributesparamètres.
- la crlf -> lfconversion ne se produit que lors de l'ajout de nouveaux fichiers, les crlffichiers déjà existants dans le référentiel ne sont pas affectés.

Moral (pour Windows):
    - utilisez core.autocrlf= truesi vous prévoyez d'utiliser également ce projet sous Unix (et ne souhaitez pas configurer votre éditeur / IDE pour utiliser les fins de ligne unix),
    - utilisez core.autocrlf= falsesi vous prévoyez d'utiliser ce projet sous Windows uniquement ( ou vous avez configuré votre éditeur / IDE pour utiliser les fins de ligne unix),
    - n'utilisez jamaiscore.autocrlf = inputsauf si vous avez une bonne raison de le faire ( par exemple, si vous utilisez des utilitaires unix sous Windows ou si vous rencontrez des problèmes de makefiles),

PS Que choisir lors de l'installation de git pour Windows?
Si vous n'utilisez aucun de vos projets sous Unix, n'acceptez pas la première option par défaut. Choisissez le troisième ( Checkout as-is, commit as-is ). Vous ne verrez pas ce message. Déjà.

PPS Ma préférence personnelle est de configurer l' éditeur / IDE pour utiliser des terminaisons de style Unix et de le paramétrer core.autocrlfsur false.


28
Pour le temps que j'ai passé pour aller aussi loin, j'espérais un core.crlf = rackoff ;-)
PandaWood

10
J'ai restructuré le contenu, peut-être que ce sera plus facile à lire de cette façon
Antony Hatchkins

7
désolé, j'espère que mon commentaire n'a pas été considéré comme une critique de votre réponse. Par "aller aussi loin", je veux dire, avant de trouver cette réponse.
PandaWood

10
C'est tellement déroutant. J'ai LF défini dans mon éditeur. Tout le code repo utilise LF. global autocrlf est défini sur false et le noyau gitconfig dans mon répertoire personnel est défini sur false. Mais je reçois toujours le message LF remplacé par CRLF
isimmons

17
Si vous avez configuré votre éditeur pour utiliser les terminaisons de style Unix, pourquoi ne pas définir core.autocrlfsur entrée? D'après ce que j'ai recueilli de votre réponse, le définir sur input garantit que le référentiel et le répertoire de travail ont toujours des fins de ligne de style Unix. Pourquoi ne voudriez-vous jamais cela dans Windows?
Hubro

764

Git a trois modes de traitement des fins de ligne:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

Vous pouvez définir le mode à utiliser en ajoutant un paramètre supplémentaire de trueou falseà la ligne de commande ci-dessus.

Si core.autocrlfest défini sur true, cela signifie que chaque fois que vous ajoutez un fichier au référentiel git que git pense être un fichier texte, il transformera toutes les fins de ligne CRLF en LF uniquement avant de le stocker dans la validation. Chaque fois que vous git checkoutquelque chose, tous les fichiers texte auront automatiquement leurs fins de ligne LF converties en fins CRLF. Cela permet de développer un projet sur des plates-formes qui utilisent différents styles de fin de ligne sans commettre étant très bruyant car chaque éditeur modifie le style de fin de ligne car le style de fin de ligne est toujours LF.

L'effet secondaire de cette conversion pratique, et c'est à cela que sert l'avertissement, est que si un fichier texte que vous avez créé à l'origine avait des terminaisons LF au lieu de CRLF, il sera stocké avec LF comme d'habitude, mais lorsqu'il est vérifié plus tard, il aura des terminaisons CRLF. Pour les fichiers texte normaux, c'est généralement très bien. L'avertissement est un "pour votre information" dans ce cas, mais au cas où git évalue incorrectement un fichier binaire comme un fichier texte, c'est un avertissement important car git corromprait alors votre fichier binaire.

Si core.autocrlfest défini sur false, aucune conversion de fin de ligne n'est effectuée, les fichiers texte sont donc archivés tels quels. Cela fonctionne généralement bien, tant que tous vos développeurs sont sous Linux ou tous sous Windows. Mais d'après mon expérience, j'ai toujours tendance à obtenir des fichiers texte avec des fins de ligne mixtes qui finissent par causer des problèmes.

Ma préférence personnelle est de laisser le paramètre activé, en tant que développeur Windows.

Voir http://kernel.org/pub/software/scm/git/docs/git-config.html pour des informations mises à jour qui incluent la valeur "input".


116
Comme dit ici ( stackoverflow.com/questions/1249932/… ), je serais respectueusement en désaccord et laisser ce paramètre sur OFF (et utiliser Notepad ++ ou tout autre éditeur capable de traiter - et de laisser tel quel - quel que soit le caractère de fin de ligne il trouve)
VonC

23
J'aime cette réponse et préfère laisser autocrlf défini sur true. Comme alternative, existe-t-il un moyen de supprimer automatiquement les messages d'avertissement?
Krisc

12
Il serait bon d'augmenter cette réponse bien écrite avec une comparaison avec les core.eolparamètres, peut-être de concert avec la .gitattributesconfiguration. J'ai essayé de comprendre les différences et les chevauchements grâce à l'expérimentation, et c'est très déroutant.
seh

5
Pour une solution plus permanente, changez votre .gitconfig en: [core] autocrlf = false
RBZ

9
Existe-t-il un moyen simple de supprimer simplement l'avertissement? Je veux que ce soit vrai et je sais que je l'ai mis à vrai. Je n'ai pas besoin de voir tous les avertissements tout le temps ... C'est OK, vraiment ...: p
UmaN

160

Si vous avez déjà extrait le code, les fichiers sont déjà indexés. Après avoir modifié vos paramètres git, dites en exécutant:

git config --global core.autocrlf input 

vous devez actualiser les index avec

git rm --cached -r . 

et réécrire l'index git avec

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Remarque: cela supprimera vos modifications locales, pensez à les ranger avant de le faire.


23
Merci pour un moyen simple, multiplateforme et clair de le FIXER, plutôt qu'une énorme discussion sur le sens de la configuration.
Eris

2
si git reset --hard est-il possible que ma modification locale soit perdue? Je viens de suivre tous les commentaires ci
Freddy Sidauruk

5
Oui, vos modifications locales seront perdues. Le paramètre --hard réinitialise l'index et l'arborescence de travail afin que toutes les modifications apportées aux fichiers suivis soient ignorées. git-scm.com/docs/git-reset
Jacques

2
Quelle est la signification de git rm --cached -r .? Pourquoi git reset --hardpas assez?
gavenkoa

2
@gavenkoa @max Vous avez besoin de git rm --cached -r .Si vous le faites git reset --hardaprès avoir modifié le core.autocrlfparamètre, il ne reconvertira pas les fins de ligne. Vous devez nettoyer l'index git.
wisbucky

80
git config core.autocrlf false

6
assurez-vous d'exécuter cette racine interne du référentiel
Hammad Khan

23
Je ne comprends pas comment cela peut être utile. La moitié des gens ont besoin que autocrlf soit vrai pour que cela fonctionne, l'autre moitié a besoin que ce soit faux / entrée. Alors, quoi, sont-ils censés jeter au hasard ces réponses uniques sur le mur de leur console jusqu'à ce que quelque chose colle et sorte "fonctionne"? Ce n'est pas productif.
Zoran Pavlovic

J'obtiens une erreur "fatal: pas dans un répertoire git". J'ai essayé de cd sur C: \ Program Files \ Git et C: \ Program Files \ Git \ bin
pixelwiz

2
Paramètre @mbb autcrlfpour falsesimplement résoudre le problème à chaque utilisateur de votre projet.
jpaugh

5
@pixelwiz: cette commande définit la propriété uniquement pour le projet (vous devez donc être sous un référentiel git pour l'exécuter). Si vous souhaitez définir cela globalement, utilisez git config --global core.autocrlf falseplutôt.
Michaël Polla

49

Les deux unix2dos et dos2unix est disponible dans les fenêtres avec gitbash. Vous pouvez utiliser la commande suivante pour effectuer la conversion UNIX (LF) -> DOS (CRLF). Par conséquent, vous n'obtiendrez pas l'avertissement.

unix2dos filename

ou

dos2unix -D filename

Mais n'exécutez pas cette commande sur un fichier CRLF existant, vous obtiendrez des sauts de ligne vides toutes les deux lignes.

dos2unix -D filenamene fonctionnera pas avec tous les systèmes d'exploitation. Veuillez vérifier ce lien pour la compatibilité.

Si, pour une raison quelconque, vous devez forcer la commande, utilisez --force. S'il indique invalide, utilisez -f.


8
Qu'est ce que ça fait?
Salman von Abbas

1
Voici ce que dit l'option d'aide: `--u2d, -D effectue la conversion UNIX -> DOS`
Larry Battle

1
@Rifat, je suis confus. Votre commentaire dit que dos2unix -Dcela convertira les fins de ligne Windows en fins de ligne Linux. N'est-ce pas la même chose que la conversion DOS (CRLF) -> UNIX (LF). Cependant, les dos2unix -hétats qui -Deffectueront la conversion UNIX (LF) -> DOS (CRLF). dos2unix Plus d'infos: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix
Larry Battle

1
@LarryBattle Oui, vous avez raison sur -D. En fait, j'ai posté la réponse quand j'étais un utilisateur Windows. Et, j'ai fait le commentaire plus d'un an plus tard quand je suis un utilisateur mac: D BTW, Merci pour la clarification.
Rifat

1
Cela a fonctionné pour moi. J'utilise Cygwin, qui ne semble pas supporter le commutateur -D - mais il y a la commande "unix2dos", qui fait la même chose. J'aimerais bien savoir ce qui a causé le problème - j'ai core.autocrlf = false et c'est un référentiel Windows uniquement.
Richard Beier

28

Je pense que la réponse de @ Basiloungas est proche mais obsolète (au moins sur Mac).

Ouvrez le fichier ~ / .gitconfig et définissez-le safecrlfsur false

[core]
       autocrlf = input
       safecrlf = false

Cela * fera ignorer le caractère de fin de ligne apparemment (cela a fonctionné pour moi, de toute façon).


1
Ça devrait être safecrlf(avec un 'f')
alpipego

22

Un article de GitHub sur les fins de ligne est souvent mentionné lorsque l'on parle de ce sujet.

Mon expérience personnelle avec l'utilisation du core.autocrlfparamètre de configuration souvent recommandé a été très mitigée.

J'utilise Windows avec Cygwin, traitant à la fois des projets Windows et UNIX à des moments différents. Même mes projets Windows utilisent parfois bashdes scripts shell, qui nécessitent des fins de ligne UNIX (LF).

En utilisant le core.autocrlfparamètre recommandé de GitHub pour Windows, si je vérifie un projet UNIX (qui fonctionne parfaitement sur Cygwin - ou peut-être que je contribue à un projet que j'utilise sur mon serveur Linux), les fichiers texte sont extraits avec Windows (CRLF ) les fins de ligne, créant des problèmes.

Fondamentalement, pour un environnement mixte comme le mien, définir le global core.autocrlfsur l'une des options ne fonctionnera pas bien dans certains cas. Cette option peut être définie sur une configuration git locale (référentiel), mais même cela ne serait pas suffisant pour un projet contenant à la fois des éléments liés à Windows et UNIX (par exemple, j'ai un projet Windows avec certains bashscripts utilitaires).

Le meilleur choix que j'ai trouvé est de créer des fichiers .gitattributes par référentiel . L' article GitHub le mentionne.
Exemple de cet article:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

Dans l'un des référentiels de mon projet:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

C'est un peu plus de choses à configurer, mais faites-le une fois par projet, et tout contributeur sur n'importe quel système d'exploitation ne devrait avoir aucun problème avec les fins de ligne lorsqu'il travaille avec ce projet.


En cours d'exécution maintenant, en essayant de gérer un dépôt avec des scripts Cygwin parmi d'autres fichiers texte de base. Comment géreriez-vous les fichiers sans extension (par exemple "fstab", "sshd_config")? L'article lié ne couvre pas ce scénario.
Mike Loux

1
@MikeLoux Essayez cette méthode: stackoverflow.com/a/44806034/4377192
Gene Pavlovsky

J'ai trouvé que cela text=false eol=falsefonctionnait de manière similaire à binary. Est-ce que ça sonne bien? Il pourrait être utile d'indiquer "Je sais que ce sont des fichiers texte, mais je ne veux pas qu'ils soient normalisés"
joeytwiddle

19

Dans vim ouvrez le fichier (ex:) :e YOURFILEENTER, puis

:set noendofline binary
:wq

2
Une simple modification avec vimlaisserait toute fin de ligne intacte.
Eye

J'ai eu ce problème avec certains fichiers Cocoapods. Ce qui précède a fixé la plupart d'entre eux; pour le reste, s / {control-v} {control-m} // a fait l'affaire. Les deux codes de contrôle forment ensemble le ^ M que ceux d'entre nous sous OS X voient souvent dans les fichiers Windows.
janineanne

16

J'ai eu ce problème également.

SVN n'effectue aucune conversion de fin de ligne, donc les fichiers sont validés avec les fins de ligne CRLF intactes. Si vous utilisez ensuite git-svn pour placer le projet dans git, les terminaisons CRLF persistent dans le référentiel git, qui n'est pas l'état dans lequel git s'attend à se trouver - la valeur par défaut étant de n'avoir que les terminaisons de ligne unix / linux (LF) enregistré.

Lorsque vous extrayez ensuite les fichiers sur Windows, la conversion autocrlf laisse les fichiers intacts (car ils ont déjà les terminaisons correctes pour la plate-forme actuelle), mais le processus qui décide s'il y a une différence avec les fichiers archivés effectue la conversion inverse avant de comparer, ce qui se traduit par ce qu'il pense être un LF dans le fichier extrait avec un CRLF inattendu dans le référentiel.

Pour autant que je puisse voir, vos choix sont:

  1. Réimportez votre code dans un nouveau dépôt git sans utiliser git-svn, cela signifie que les fins de ligne sont converties dans le commit git initial --all
  2. Définissez autocrlf sur false et ignorez le fait que les fins de ligne ne sont pas dans le style préféré de git
  3. Extrayez vos fichiers avec autocrlf désactivé, corrigez toutes les fins de ligne, réarchivez tout et rallumez-le.
  4. Réécrivez l'historique de votre référentiel afin que la validation d'origine ne contienne plus le CRLF auquel git ne s'attendait pas. (Les mises en garde habituelles concernant la réécriture de l'histoire s'appliquent)

Note de bas de page: si vous choisissez l'option # 2, mon expérience est que certains des outils auxiliaires (rebase, correctif, etc.) ne gèrent pas les fichiers CRLF et vous vous retrouverez tôt ou tard avec des fichiers avec un mélange de CRLF et LF (ligne incohérente) terminaisons). Je ne connais aucun moyen de tirer le meilleur parti des deux.


2
Je pense qu'il y a une quatrième option à ajouter à votre liste, en supposant que l'on puisse se permettre de réécrire l'historique: vous pouvez prendre un dépôt git que vous avez initialement créé avec git-svn et réécrire son historique pour ne plus avoir de sauts de ligne CRLF. Cela vous donnerait des sauts de ligne normalisés s'étendant vers l'arrière tout au long de votre historique svn. L'utilisateur keo présente une solution sur stackoverflow.com/a/1060828/64257 .
Chris

À propos de votre note de bas de page: rebasen'a aucun problème avec CRLF. Le seul problème que je connaisse est que l'outil de fusion git standard insérera ses marqueurs de conflit ("<<<<<<", ">>>>>>" etc.) avec LF uniquement, donc un fichier avec des marqueurs de conflit ont des fins de ligne mixtes. Cependant, une fois que vous avez retiré les marqueurs, tout va bien.
sleske

Il est possible que la manipulation de git ait changé au cours des 3 dernières années, c'était mon expérience directe avec lui à l'époque, je n'ai pas eu besoin de revoir ce problème particulier depuis. ymmv.
Tim Abell

1
@sleske à partir de git 2.8, les marqueurs de fusion n'introduiront plus de fin de ligne mixte. Voir stackoverflow.com/a/35474954/6309
VonC

@VonC: C'est cool. Bon à savoir pour les moments où je dois travailler sur Windows.
sleske

12

Suppression des éléments ci-dessous du fichier ~ / .gitattributes

* text=auto

empêchera git de vérifier les fins de ligne en premier lieu.


6
Incorrect. Cette ligne, si elle est présente, remplacera la configuration de core.autocrlf. Si cela est défini sur 'true', alors non, la suppression de cette ligne n'empêchera pas git de vérifier les fins de ligne.
Arafangion

1
Néanmoins, si core.autocrlf est défini sur false, si celui-ci n'est pas supprimé, définir l'autocrlf sur false n'aidera pas beaucoup, donc celui-ci m'a aidé (mais n'est pas suffisant en soi).
Matty

2
Vote en faveur de cela !! Bien que la partie «va empêcher git de vérifier» n'est pas techniquement correcte, c'est la SEULE réponse qui mentionne spécifiquement le text=paramètre .gitattributes(qui, s'il est présent, SERA un bloqueur). Les autres réponses sont donc incomplètes. Je devenais fou en essayant de comprendre pourquoi mes fichiers continuaient à apparaître comme "modifiés", peu importe combien de fois j'ai changé mes paramètres autocrlfet j'ai safecrlfvérifié et effacé le cache git et la réinitialisation matérielle.
jdunk

10

Il devrait se lire:

avertissement: ( Si vous l'extrayez / ou clonez vers un autre dossier avec votre core.autocrlf actueltrue ), LF sera remplacé par CRLF

Le fichier aura sa fin de ligne d'origine dans votre répertoire de travail ( actuel ).

Cette image devrait expliquer ce que cela signifie. entrez la description de l'image ici


Cela signifie également que ce qui est envoyé à Subversion (si vous le faites) aura la conversion.
jpaugh

10

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

Faire cela sur un commit séparé ou git peut toujours voir des fichiers entiers modifiés lorsque vous apportez une seule modification (selon que vous avez changé l'option autocrlf)

Celui-ci fonctionne vraiment. Git respectera les fins de ligne dans les projets de fin de ligne mixte et ne vous en avertira pas.


2
Cela est particulièrement utile lorsque vous souhaitez effectuer une conversion entre CRLF et LF, mais vous disposez de quelques fichiers .sh qui doivent rester intacts. J'utilise *.sh -crlftout le temps ...
MartinTeeVarga

9

Je ne connais pas grand chose à git sous Windows, mais ...

Il me semble que git convertit le format de retour pour correspondre à celui de la plate-forme en cours d'exécution (Windows). CRLF est le format de retour par défaut dans Windows, tandis que LF est le format de retour par défaut pour la plupart des autres systèmes d'exploitation.

Il y a de fortes chances que le format de retour soit ajusté correctement lorsque le code est déplacé vers un autre système. Je pense également que git est assez intelligent pour garder les fichiers binaires intacts plutôt que d'essayer de convertir des LF en CRLF en, disons, des JPEG.

En résumé, vous n'avez probablement pas besoin de trop vous inquiéter de cette conversion. Cependant, si vous allez archiver votre projet en tant que tarball, les autres codeurs apprécieraient probablement d'avoir des terminateurs de ligne LF plutôt que CRLF. En fonction de ce qui vous intéresse (et si vous n'utilisez pas le Bloc-notes), vous voudrez peut-être configurer git pour utiliser les retours LF si vous le pouvez :)

Annexe: CR est le code ASCII 13, LF est le code ASCII 10. Ainsi, CRLF est de deux octets, tandis que LF en est un.


5
Comme personne ne semble l'avoir dit, CR signifie "Carriage Return" et LF signifie "Line Feed". Comme deuxième note, de nombreux éditeurs de fenêtres modifient silencieusement un fichier texte avec le caractère LF indiquant une nouvelle ligne pour être à la place la paire de caractères CRLF. L'utilisateur de l'éditeur ne sera même pas averti, mais Git verra le changement.
user2548343

7

Assurez-vous que vous avez installé le dernier git.
J'ai fait comme ci git config core.autocrlf false- dessus , lors de l'utilisation de git (version 2.7.1), mais cela n'a pas fonctionné.
Ensuite, cela fonctionne maintenant lors de la mise à niveau de git (de 2.7.1 à 2.20.1).


Je pense que vous vouliez dire que vous aviez git 2.17.1. J'avais le même problème et j'ai fait la mise à jour et cela l'a également corrigé. Heureux d'avoir vu votre réponse!
Phillip McMullen

5
  1. Ouvrez le fichier dans le Bloc-notes ++.
  2. Allez dans Edition / Conversion EOL.
  3. Cliquez sur le format Windows.
  4. Enregistrez le fichier.

1
Essayez également d'utiliser git config --global core.autocrlf falsepour empêcher Git de définir les fins de ligne Unixsur une validation. Faites un suivi avec git config core.autocrlfpour vérifier qu'il est bien réglé sur faux.
Contango

5

La question d'OP est liée à Windows et je ne pouvais pas en utiliser d'autres sans aller dans le répertoire ou même exécuter le fichier dans Notepad ++ car l'administrateur ne fonctionnait pas. Il fallait donc suivre cette voie:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

3

De nombreux éditeurs de texte vous permettent de passer à LF, voir les instructions Atom ci-dessous. Simple et explicite.


Cliquez CRLFen bas à droite:

entrez la description de l'image ici

Sélectionnez LFdans la liste déroulante en haut:

entrez la description de l'image ici


2

Dans une invite de shell GNU / Linux, les commandes dos2unix et unix2dos vous permettent de convertir / formater facilement vos fichiers provenant de MS Windows


2

CRLF pourrait causer des problèmes lors de l'utilisation de votre "code" dans deux systèmes d'exploitation différents (Linux et Windows). Mon script python a été écrit dans un conteneur Docker Linux puis poussé à l'aide de Windows git-bash. Il m'a donné l'avertissement que LF sera remplacé par CRLF. Je n'y ai pas beaucoup réfléchi, mais quand j'ai commencé le script plus tard, il a dit /usr/bin/env: 'python\r': No such file or directory. Maintenant que c'est une \rramification pour vous. Windows utilise "CR" - retour chariot - au-dessus de '\ n' comme nouveau caractère de ligne - \n\r. C'est quelque chose que vous devrez peut-être considérer.


0

La plupart des outils de Windows n'acceptent que LF dans les fichiers texte. Par exemple, vous pouvez contrôler le comportement de Visual Studio dans un fichier nommé «.editorconfig» avec l'exemple de contenu (partie) suivant:

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Seul le bloc-notes Windows d'origine ne fonctionne pas avec LF mais il existe d'autres outils d'édition simples plus appropriés!

Par conséquent, vous devez également utiliser LF dans les fichiers texte sous Windows. C'est mon message, stronlgy recommandé! Il n'y a aucune raison d'utiliser CRLF dans Windows!

(La même discussion utilise \ in include chemins en C / ++, c'est des conneries, utilisez #include <pathTo / myheader.h> avec slash !, C'est le standard C / ++ et tous les compilateurs Microsoft le supportent).

Par conséquent, le paramètre approprié pour git est

git config core.autocrlf false

Mon message: Oubliez les vieux programmes de réflexion comme dos2unix et unix2dos. Précisez dans votre équipe que LF est approprié à utiliser sous Windows.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.