git remplace LF par CRLF

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 à true, cela signifie que chaque fois que vous ajoutez un fichier au git repo que git pense être un fichier texte, il tournera toutes les fins de ligne CRLF à juste LF avant qu'il ne le stocke dans la propagation. Chaque fois que vous git checkout quelque chose, tous les fichiers texte verront automatiquement leurs fins de ligne LF converties en fins de ligne CRLF. Cela permet le développement d'un projet à travers des plates-formes qui utilisent différents styles de terminaison de ligne sans être très bruyant car chaque éditeur change le style de terminaison de ligne car le style de terminaison de ligne est toujours invariablement LF.

l'effet secondaire de cette conversion commode, et c'est ce que l'avertissement que vous voyez est au sujet, est que si un fichier de texte que vous avez écrit à l'origine avait LF les fins au lieu de CRLF, il sera stocké avec LF comme d'habitude, mais quand vérifié plus tard, il aura des fins CRLF. Pour les fichiers texte normaux, c'est généralement très bien. L'avertissement est une "pour votre information" dans ce cas, mais dans le cas où git de manière incorrecte évalue un fichier binaire d'un fichier texte, c'est un avertissement important parce que git serait alors de corrompre votre fichier binaire.

si core.autocrlf est défini à false, aucune conversion de fin de ligne n'est jamais effectuée, donc les fichiers texte sont enregistrés en tant que-est. C'est généralement ok, tant que tous vos développeurs sont soit sur Linux ou sur Windows. Mais d'après mon expérience, j'ai toujours tendance à obtenir des fichiers texte avec des fins de ligne mélangées qui finissent par causer des problèmes.

Ma préférence personnelle est de laisser le réglage allumé, comme un développeur de fenêtres.

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

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

le concept de autocrlf est de traiter les conversions de fin de ligne de façon transparente. Et il le fait!

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

Bonne nouvelle: il ne doit être effectué qu'une seule fois par installation git (un réglage par projet est également possible).

Comment autocrlf fonctionne :

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 de style win, lf = style unix (et Mac osx).

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

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

– autocrlf = true si vous avez unix-style lf dans un de vos fichiers (=rarement),

    – autocrlf = input si vous avez win-style crlf dans l'un de vos fichiers (= presque toujours),

    - autocrlf = false - jamais!

que signifie Cet avertissement

L'avertissement " LF sera remplacé par un CRLF " dit que vous (avoir autocrlf = true ) perdrez votre style unix (LF après commit-checkout cycle (il sera remplacé par windows-style CRLF). Git ne s'attend pas à ce que vous utilisiez unix-style LF sous windows.

L'avertissement " CRLF sera remplacé par LF " dit que vous (avoir autocrlf = input ) perdrez votre style windows CRLF après une validation-contrôle du cycle (il sera remplacé par style unix (LF). N'utilisez pas input sous windows.

encore une autre façon de montrer comment autocrlf œuvres

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

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

file to commit -> repository -> checked out file

comment fixer

valeur par défaut pour core.autocrlf est sélectionnée lors de l'installation de Git et stockée dans gitconfig ( %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
1519510920"    – "local" (par-pensions) gitconfig à .git/config dans le travail dir.

ainsi, écrire git config core.autocrlf dans le dir de travail pour vérifier la valeur actuellement utilisée et

- ajouter autocrlf=false à gitconfig pour l'ensemble du système         # solution par système

   - git config --global core.autocrlf false # solution par utilisateur

   - git config --local core.autocrlf false # solution par projet

mises en garde

– Les paramètres git config peuvent être remplacés par les paramètres gitattributes .

– La conversion crlf -> lf ne se produit que lors de l'ajout de nouveaux fichiers, les fichiers crlf existant déjà dans les pensions ne sont pas touchés.

Moral (Pour Windows):

    - utilisez core.autocrlf = true si vous prévoyez d'utiliser ce projet sous Unix (et que vous ne voulez pas configurer votre éditeur / IDE pour utiliser les terminaisons de ligne unix),

    - utilisez core.autocrlf = false si vous prévoyez D'utiliser ce projet sous Windows Seulement (ou si vous avez configuré votre éditeur/IDE pour utiliser les terminaisons de ligne unix)),

    - jamais utiliser core.autocrlf = input à moins que vous ayez une bonne raison de ( eg si vous utilisez des utilitaires unix sous windows ou si vous rencontrez des makefiles),

PS que choisir lors de l'installation de Git for Windows?

Si vous n'allez pas utiliser l'un de vos projets sous Unix, ne pas d'accord avec l' première option par défaut. Choisissez la troisième ( passer à la Caisse, s'engager en tant qu'-est ). Vous ne verrez pas ce message. Jamais.

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

Si vous avez déjà vérifié le code, les fichiers sont déjà indexés. Après avoir changé vos paramètres git, vous devriez rafraîchir 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

git config core.autocrlf false

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

unix2dos filename

ou

dos2unix -D filename

mais, n'exécutez pas cette commande sur un fichier CRLF existant, alors vous obtiendrez des lignes vides toutes les deux lignes.

dos2unix -D filename ne fonctionnera pas avec chaque système d'exploitation. S'il vous plaît vérifier ce lien pour la compatibilité.

si, pour une raison quelconque, vous devez forcer la commande, utilisez --force . S'il est indiqué "invalide", utilisez -f .

je pense que la réponse de @Basiloungas 151940920" est close mais périmée (au moins sur Mac).

[core]
       autocrlf = input
       safecrlf = false

in vim ouvrir le fichier (e.g.: :e YOURFILE ENTER ), puis

:set noendofline binary
:wq

j'ai eu ce problème aussi.

SVN ne fait pas de conversion de fin de ligne, donc les fichiers sont engagés avec les fins de ligne CRLF intactes. Si vous utilisez ensuite git-svn pour mettre le projet dans git, alors les terminaisons CRLF persistent dans le dépôt git, ce qui n'est pas l'état dans lequel git s'attend à se trouver - la valeur par défaut étant que les terminaisons de ligne unix/linux (LF) sont vérifiées.

lorsque vous consultez les fichiers sous windows, l'autocrlf la conversion laisse les fichiers intacts (car ils ont déjà les terminaisons correctes pour la plate-forme actuelle), cependant le processus qui décide s'il y a une différence avec les fichiers vérifiés effectue la conversion inverse avant comparer, résultant en comparant ce qu'il pense est un LF dans le fichier vérifié avec un CRLF inattendu dans le dépôt.

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 l'intial git commit --all
2. placer autocrlf à false, et ignorer le fait que les fins de ligne ne sont pas dans le style préféré de git
3. Vérifiez vos fichiers avec autocrlf désactivé, fixez toutes les terminaisons de la ligne, vérifiez tout retour dans, et le remettre en marche.
4. réécrire les l'histoire pour que le commit original ne contienne plus le CRLF que git n'attendait pas. (Les mises en garde habituelles à propos de l'histoire de réécriture s'appliquent)

note de bas de page: si vous choisissez l'option #2, Alors mon expérience est que certains des outils auxiliaires (rebase, patch etc) ne traitent pas les fichiers CRLF et vous finirez tôt ou tard avec des fichiers avec un mélange de CRLF et LF (fin de ligne incohérente). Je ne connais aucun moyen de obtenir le meilleur des deux.

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

mon expérience personnelle avec l'utilisation du réglage de configuration souvent recommandé core.autocrlf 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 des scripts shell bash , qui nécessitent des fins de ligne UNIX (LF).

en utilisant le paramètre recommandé par GitHub core.autocrlf pour Windows, si je consulte 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 vérifiés avec les fins de ligne de Windows (CRLF), créant des problèmes.

fondamentalement, pour un environnement mixte comme je l'ai, mettre le global core.autocrlf à l'une des options ne fonctionnera pas bien dans certains cas. Cette option pourrait être défini sur une configuration git locale (de dépôt), mais même cela ne serait pas suffisant pour un projet qui contient à la fois des éléments liés à Windows et à UNIX (par exemple, j'ai un projet Windows avec quelques scripts utilitaires bash ).

le meilleur choix que j'ai trouvé est de créer par dépôt .gitattributes "1519210920 de fichiers". L'article de GitHub le mentionne.

Exemple tiré 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

* 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