git remplaçant LF par CRLF

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.

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

où 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.

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".

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.

git config core.autocrlf false

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.

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).

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.

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

:set noendofline binary
:wq

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.

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

* text=auto

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

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.

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.

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.

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).

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

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

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

Cliquez CRLFen bas à droite:

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

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

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.

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.