Windows git «avertissement: LF sera remplacé par CRLF», est-ce que cet avertissement est en arrière?

env:

• Windows 7
• msysgit

Wheng I git commit , il dit:

warning: LF will be replaced by CRLF. 

Cet avertissement est-il en arrière?
J'édite un fichier dans Windows, la fin de la ligne est CRLF, tout comme cette image:

Et git le change LFpour la validation du dépôt.
Je pense donc que l'avertissement correct est:

warning: CRLF will be replaced by LF. 

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

OUI l'avertissement est à l'envers.

Et en fait, cela ne devrait même pas être un avertissement en premier lieu. Parce que tout cet avertissement dit (mais à l'envers malheureusement) est que les caractères CRLF dans votre fichier avec les fins de ligne Windows seront remplacés par LF lors de la validation. Ce qui signifie qu'il est normalisé aux mêmes fins de ligne que celles utilisées par * nix et MacOS.

Rien d'étrange ne se passe, c'est exactement le comportement que vous souhaiteriez normalement.

Cet avertissement dans sa forme actuelle est l'une des deux choses suivantes:

1. Un bug malheureux combiné à un message d'avertissement trop prudent, ou
2. Une intrigue très intelligente pour vous faire vraiment réfléchir à cela ...

;)

--Mise à jour le 9 juillet ---

Suppression de "C'est correct et précis" comme l'a commenté @mgiuca

======

NON . Il ne parle PAS de vos fichiers actuellement avec CRLF. Il s'agit plutôt de fichiers avec LF.

Il devrait lire:

avertissement: ( Si vous le récupérez / ou le clonez dans un autre dossier avec votre configuration core.autocrlf actuelle ,) LF sera remplacé par CRLF

Le fichier aura ses fins de ligne d'origine dans votre répertoire de travail ( actuel ).

Cette image devrait expliquer ce que cela signifie.

Tout cela suppose core.autocrlf=true

Erreur d'origine:

avertissement: LF sera remplacé par CRLF
Le fichier aura ses fins de ligne d'origine dans votre répertoire de travail.

Ce que l'erreur DEVRAIT lire:

avertissement: LF sera remplacé par CRLF dans votre répertoire de travail
Le fichier aura ses fins de ligne LF d'origine dans le référentiel git

Explication ici :

L'effet secondaire de cette conversion pratique, et c'est le sujet de l'avertissement que vous voyez, 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 une fois coché 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 dans le cas où git évalue incorrectement un fichier binaire comme étant un fichier texte, c'est un avertissement important car git corromprait alors votre fichier binaire.

Fondamentalement, un fichier local qui était auparavant LF aura désormais CRLF localement

git config --global core.autocrlf false fonctionne bien pour les paramètres globaux.

Mais si vous utilisez Visual Studio, vous devrez peut-être également modifier .gitattributespour certains types de projets ( par exemple, une application de bibliothèque de classes c # ):

• supprimer la ligne * text=auto

Après avoir défini, core.autocrlf=truej'obtenais "LF sera remplacé par CRLF" (notez pas "CRLF sera remplacé par LF") lorsque j'utilisais git add(ou peut-être était-ce activé git commit?) Des fichiers modifiés dans Windows sur un référentiel (qui utilise LF) qui a été vérifié avant mon départcore.autocrlf=true .

J'ai effectué un nouveau paiement avec core.autocrlf=trueet maintenant je ne reçois pas ces messages.

Si vous utilisez Visual Studio 2017, 2019, vous pouvez:

1. ouvrez le .gitignore principal (mettez à jour ou supprimez d'autres fichiers .gitignore dans d'autres projets de la solution)
2. collez le code ci-dessous:

[core]
 autocrlf = false
[filter "lfs"]
 required = true
 clean = git-lfs clean -- %f
 smudge = git-lfs smudge -- %f
 process = git-lfs filter-process

Faites juste une chose simple:

1. Ouvrez git-hub (Shell) et accédez au fichier de répertoire auquel appartient (cd / a / b / c / ...)
2. Exécutez dos2unix (parfois dos2unix.exe)
3. Essayez de vous engager maintenant. Si vous obtenez à nouveau la même erreur. Effectuez toutes les étapes ci-dessus sauf au lieu de dos2unix, faites unix2dox (unix2dos.exe parfois)