Question git remplaçant LF avec CRLF


Exécution de git sur une machine Windows XP, en utilisant bash. J'ai exporté mon projet de SVN, puis cloné un dépôt 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? Ceci est une solution .NET dans Visual Studio.


657
2017-12-27 23:21


origine


Réponses:


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 true ou false à la ligne de commande ci-dessus.

Si core.autocrlf est défini sur true, ce qui signifie que chaque fois que vous ajoutez un fichier au dépôt git que git pense être un fichier texte, toutes les fins de ligne CRLF sont converties en LF avant d'être stockées dans le commit. Quand tu git checkout Quelque chose, tous les fichiers texte auront automatiquement leurs fins de ligne LF converties en terminaisons CRLF. Cela permet le développement d'un projet sur des plates-formes utilisant des styles de fin de ligne différents sans que les commits soient très bruyants 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 ce que l'avertissement que vous voyez est, 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 coché plus tard, il aura des fins 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 dans le cas où git estime incorrectement qu'un fichier binaire est un fichier texte, c'est un avertissement important car git serait alors corrompre votre fichier binaire.

Si core.autocrlf est défini sur false, aucune conversion de fin de ligne n'est jamais effectuée, de sorte que les fichiers texte sont archivés tels quels. Cela fonctionne généralement bien, tant que tous vos développeurs sont sous Linux ou sous Windows. Mais dans 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 les informations mises à jour qui incluent la valeur "entrée".


683
2017-12-28 04:37



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

Le concept de autocrlf est 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 fois par installation git (par paramètre de projet est également possible).

Comment autocrlf travaux:

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

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

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

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

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

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

Que signifie cet avertissement?

L'avertissement "LF sera remplacé par CRLF"dit que vous (ayant autocrlf=true) perdra votre LF de type unix après le cycle de validation-validation (il sera remplacé par un CRLF de type windows). Git ne s'attend pas à ce que vous utilisiez un LF de type unix sous Windows.

L'avertissement "CRLF sera remplacé par LF"dit que vous (ayant autocrlf=input) perdra votre CRLF Windows après un cycle commit-checkout (il sera remplacé par un LF unix). Ne pas utiliser input sous les fenêtres.

Encore une autre façon de montrer comment autocrlf travaux

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

X est soit CRLF (style windows) ou LF (style unix) et les flèches représentent

file to commit -> repository -> checked out file

Comment réparer

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

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

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

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

Avertissements
  - git config les paramètres peuvent être remplacés par gitattributes paramètres.
  - crlf -> lf la conversion ne se produit que lors de l'ajout de nouveaux fichiers, crlf les fichiers déjà présents dans le repo ne sont pas affectés.

Moral (Pour les fenêtres):
  - utilisation core.autocrlf = true si vous envisagez d'utiliser également ce projet sous Unix (et que vous ne voulez pas configurer votre éditeur / IDE pour utiliser les terminaisons de ligne unix),
  - utilisation core.autocrlf = false si vous envisagez d'utiliser ce projet sous Windows uniquement (ou si vous avez configuré votre éditeur / IDE pour utiliser les fins de ligne unix),
  - jamais utilisation core.autocrlf = input sauf si vous avez une bonne raison de (par exemple si vous utilisez des utilitaires UNIX sous Windows ou si vous rencontrez des problèmes avec makefiles),

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

PPS Ma préférence personnelle est la configuration du éditeur / IDE pour utiliser des terminaisons de style Unix, et le réglage core.autocrlf à false.


629
2018-04-27 06:33



Si vous avez déjà extrait le code, les fichiers sont déjà indexés. Après avoir modifié vos paramètres git, 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


82
2018-03-21 04:34



git config core.autocrlf false

76
2018-05-01 23:50



Tous les deux unix2dos et dos2unix est disponible dans windows avec gitbash. Vous pouvez utiliser la commande suivante pour effectuer une 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 retours à la ligne vides toutes les deux lignes.

dos2unix -D filename ne fonctionnera pas avec tous les systèmes d'exploitation. Vérifiez s'il vous plaît ce lien pour la compatibilité.

Si pour une raison quelconque vous devez forcer la commande, utilisez --force. Si elle est invalide, alors utilisez -f.


43
2017-07-19 08:10



Je pense @ Basiloungas répondre est proche mais démodé (au moins sur Mac).

Ouvrez le fichier ~ / .gitconfig et définissez safecrlf à faux

[core]
       autocrlf = input
       safecrlf = false

Cela * va faire ignorer la fin de la ligne char apparemment (travaillé pour moi, de toute façon).


22
2018-02-21 10:08



In vim ouvrir le fichier (par exemple: :e YOURFILEENTRER), puis

:set noendofline binary
:wq

14
2017-12-15 17:29