avertissement: LF sera remplacé par CRLF.
Selon l'éditeur que vous utilisez, un fichier texte avec LF ne serait pas nécessairement enregistré avec CRLF: les éditeurs récents peuvent conserver le style eol. Mais ce paramètre de configuration git insiste pour changer ceux-ci ...
Assurez-vous simplement que (comme je le recommande ici ):
git config --global core.autocrlf false
De cette façon, vous évitez toute transformation automatique et pouvez toujours les spécifier via un .gitattributesfichier et des core.eoldirectives .
windows git "LF sera remplacé par CRLF"
Cet avertissement est-il en arrière?
Non: vous êtes sous Windows et la git configpage d'aide mentionne
Utilisez ce paramètre si vous souhaitez avoir des CRLFfins de ligne dans votre répertoire de travail même si le référentiel n'a pas de fins de ligne normalisées.
Comme décrit dans " git remplaçant LF par CRLF ", cela ne devrait se produire qu'au moment de la vérification (pas de validation), avec core.autocrlf=true.
repo
/ \
crlf->lf lf->crlf
/ \
Comme mentionné dans la réponse de XiaoPeng , cet avertissement est le même que:
avertissement: (Si vous le récupérez / ou le clonez dans un autre dossier avec votre core.autocrlfconfiguration actuelle ,) LF sera remplacé par CRLF
Le fichier aura ses fins de ligne d'origine dans votre répertoire de travail (actuel).
Comme mentionné dans le git-for-windows/gitnuméro 1242 :
Je pense toujours que ce message est déroutant, le message pourrait être étendu pour inclure une meilleure explication du problème, par exemple: "LF sera remplacé par CRLF file.jsonaprès avoir supprimé le fichier et vérifié à nouveau".
Remarque: Git 2.19 (septembre 2018), lors de l'utilisation core.autocrlf, le faux avertissement "LF sera remplacé par CRLF" est maintenant supprimé .
Comme quaylar à juste titre les commentaires , s'il y a une conversion lors de la validation, il est à LFseulement.
Cet avertissement spécifique " LF will be replaced by CRLF" provient de convert.c # check_safe_crlf () :
if (checksafe == SAFE_CRLF_WARN)
warning("LF will be replaced by CRLF in %s.
The file will have its original line endings
in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
die("LF would be replaced by CRLF in %s", path);
Il est appelé par convert.c#crlf_to_git(), lui-même appelé par convert.c#convert_to_git(), lui-même appelé par convert.c#renormalize_buffer().
Et ce dernier renormalize_buffer()n'est appelé que par merge-recursive.c#blob_unchanged().
Je soupçonne donc que cette conversion ne se produit git commitque si ledit commit fait partie d'un processus de fusion.
Remarque: avec Git 2.17 (Q2 2018), un nettoyage de code ajoute quelques explications.
Voir commit 8462ff4 (13 janvier 2018) de Torsten Bögershausen ( tboegi) .
(Fusionné par Junio C Hamano - gitster- in commit 9bc89b1 , 13 févr.2018 )
convert_to_git (): safe_crlf / checksafe devient int conv_flags
Lors de l'appel convert_to_git(), le checksafeparamètre définit ce qui doit se passer si la conversion EOL ( CRLF --> LF --> CRLF) n'effectue pas un aller-retour proprement.
En outre, il a également défini si les fins de ligne doivent être renormalisées (CRLF --> LF ) ou conservées telles quelles.
checksafe était une safe_crlfénumération avec ces valeurs:
SAFE_CRLF_FALSE: do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL: die in case of EOL roundtrip errors
SAFE_CRLF_WARN: print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF: keep all line endings as they are
Notez qu'une régression introduite dans 8462ff4 (" convert_to_git():
safe_crlf/checksafedevient int conv_flags", 2018-01-13, Git 2.17.0) dans le cycle Git 2.17 a provoqué des autocrlfréécritures pour produire un message d'avertissement
malgré le réglagesafecrlf=false .
See commit 6cb0912 (04 juin 2018) par Anthony Sottile ( asottile) .
(Fusionné par Junio C Hamano - gitster- in commit 8063ff9 , 28 juin 2018)
