Git remplace LF par CRLF

Question

Sur une machine Windows, j'ai ajouté quelques fichiers en utilisant git add. J'ai reçu des avertissements disant :

LF sera remplacé par CRLF

Quelles sont les conséquences de cette conversion ?

Answer 1

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

Le concept de autocrlf est de gérer les conversions de fins de ligne de manière transparente. Et ça marche!

Mauvaise nouvelle : la valeur doit être configurée manuellement.

Bonne nouvelle : cela ne doit être fait qu'une seule fois par installation Git (la configuration par projet est également possible).

Comment autocrlf fonctionne:

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

    dépôt                  dépôt                  dépôt
     ^      V                 ^      V                 ^      V
    /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \
   /            \           /            \           /            \

Ici crlf = marqueur de fin de ligne de style win, lf = de style unix (également utilisé sur Mac depuis Mac OS X).

(pre-osx cr n'est pas affecté pour aucune des trois options ci-dessus.)

Quand ce message d'avertissement apparaît-il (sous Windows)?

- autocrlf = true si vous avez des lf de style unix dans l'un de vos fichiers (= RAREMENT),
- autocrlf = input si vous avez des crlf de style win dans l'un de vos fichiers (= presque TOUJOURS),
- autocrlf = false - JAMAIS!

Que signifie ce message d'avertissement?

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

Le avertissement "CRLF sera remplacé par LF" indique que vous (ayant autocrlf = input) perdrez votre CRLF de style windows après un cycle de validation-extraction (il sera remplacé par LF de style unix). N'utilisez pas input sous Windows.

Encore une manière de montrer comment autocrlf fonctionne

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

où x est soit CRLF (de style windows) ou LF (de style unix) et les flèches représentent

fichier à valider -> dépôt -> fichier extrait

Comment corriger

La valeur par défaut de core.autocrlf est sélectionnée lors de l'installation de Git et stockée dans le gitconfig système (%ProgramFiles(x86)%\git\etc\gitconfig sur Windows, /etc/gitconfig sur Linux). Il existe également (cascadant dans l'ordre suivant) :

- "global" (par utilisateur) gitconfig situé à ~/.gitconfig, un autre
- "global" (par utilisateur) gitconfig à $XDG_CONFIG_HOME/git/config ou $HOME/.config/git/config et
- "local" (par projet) gitconfig à .git/config dans le répertoire de travail.

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

- git config --system core.autocrlf false # solution par système
- git config --global core.autocrlf false # solution par utilisateur
- git config --local core.autocrlf false # solution par projet

Avertissements

- Les paramètres de git config peuvent être remplacés par les paramètres de gitattributes.
- La conversion crlf -> lf n'a lieu que lors de l'ajout de nouveaux fichiers, les fichiers crlf déjà existants dans le dépôt ne sont pas affectés.

Morale (pour Windows) :

- utilisez core.autocrlf = true si vous prévoyez d'utiliser ce projet sous Unix également (et que vous ne souhaitez pas configurer votre éditeur/IDE pour utiliser des fins de ligne unix),
- utilisez core.autocrlf = false si vous prévoyez d'utiliser ce projet sous Windows uniquement (ou si vous avez configuré votre éditeur/IDE pour utiliser des fins de ligne unix),
- ne utilisez jamais core.autocrlf = input à moins d'avoir une bonne raison (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'allez pas utiliser vos projets sous Unix, ne acceptez pas la première option par défaut. Choisissez la troisième option (Valider tel quel, extraire tel quel). Vous ne verrez plus ce message. Jamais.

PPS : Ma préférence personnelle est de configurer l'éditeur/IDE pour utiliser des fins de ligne de style unix et de définir core.autocrlf sur false.

Mise à jour (2022)

Depuis 2018, git peut --renormalize le dépôt en fixant les fins de ligne existantes comme requis.

Answer 2

Git a trois modes de traitement des fins de ligne :

# Cette commande affichera "true" ou "false" ou "input"
git config core.autocrlf

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

Si core.autocrlf est défini sur true, cela signifie qu'à chaque fois que vous ajoutez un fichier au dépôt Git que Git considère comme un fichier texte, il convertira toutes les fins de ligne CRLF en LF avant de le stocker dans le commit. Chaque fois que vous faites un git checkout, tous les fichiers texte auront automatiquement leurs fins de ligne LF converties en fins de ligne CRLF. Cela permet le développement d'un projet sur des plateformes utilisant différents styles de fins de ligne sans que les commits soient très bruyants, car chaque éditeur change le style de fin de ligne pour que le style de fin de ligne soit toujours de manière cohérente LF.

L'effet secondaire de cette conversion pratique, et c'est de quoi parle l'avertissement que vous voyez, c'est que si un fichier texte que vous avez écrit avait à l'origine des fins de ligne LF au lieu de CRLF, il sera stocké avec LF comme d'habitude, mais lorsqu'il est vérifié ultérieurement, il aura des fins de ligne CRLF. Pour les fichiers texte normaux, cela est généralement acceptable. L'avertissement est là pour votre information dans ce cas, mais si Git évalue incorrectement un fichier binaire comme étant un fichier texte, c'est un avertissement important, car Git serait alors en train de corrompre votre fichier binaire.

Si core.autocrlf est défini sur false, aucune conversion de fin de ligne n'est jamais effectuée, donc les fichiers texte sont enregistrés tels quels. Cela fonctionne généralement bien, tant que tous vos développeurs sont soit sur Linux, soit tous sur Windows. Mais dans mon expérience, j'ai 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 git-config pour des informations mises à jour incluant la valeur "input".

Answer 3

git config core.autocrlf false

Answer 4

À la fois unix2dos et dos2unix sont disponibles sur Windows avec Git Bash. Vous pouvez utiliser la commande suivante pour effectuer la conversion UNIX (LF) → DOS (CRLF). Vous ne recevrez donc pas d'avertissement.

unix2dos filename

ou

dos2unix -D filename

Cependant, ne lancez pas cette commande sur un fichier CRLF existant, car vous obtiendrez alors des sauts de ligne vides toutes les deux lignes.

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

Si pour une raison quelconque vous avez besoin de forcer la commande, utilisez --force. Si cela indique une erreur, utilisez -f.

Answer 5

Dans Vim, ouvrez le fichier (par exemple : :e YOURFILEENTER), puis

:set noendofline binary
:wq