使用 tortoisegit 提交项目时，出现LF will be replaced by CRLF in...

Question

在提交项目时，出现一堆warning：LF will be replaced by CRLF in...，一直卡在更新索引，准备提交那儿，在网上查了，说是换行符的问题，解决办法 git config --global core.autocrlf false即可解决，然而我这里没有效果，不知是哪里的问题，哪位大神帮忙看下。下面是config中的内容

Answer 1

Avant de répondre à votre question, je dois dire quelques mots supplémentaires. Lorsque vous collaborez au développement de code avec d'autres via GitHub ou d'autres serveurs d'hébergement distants, il est important de vous assurer que les sauts de ligne sont gérés correctement. Tout d'abord, vous devez savoir que différents systèmes d'exploitation ont des définitions différentes des caractères de nouvelle ligne. Le caractère de nouvelle ligne dans les systèmes d'exploitation Unix ou de type Unix est appelé LF, tandis que le caractère de nouvelle ligne dans les systèmes Windows est appelé LF. 🎜>CRLF

Il y a une grande différence entre les deux :

.

Dans les systèmes Unix, la fin de chaque ligne est uniquement "<line feed>", qui est "n" ; dans les systèmes Windows, la fin de chaque ligne est "<line feed><carriage retour>"

Remarque : cité à partir de la différence entre le retour chariot (CR) et le saut de ligne (LF), 'r' et 'n'.

C'est la racine du problème - c'est-à-dire que si vous utilisez un système Windows et que votre ami utilise un Mac, lorsque vous utilisez git pour développer des logiciels en collaboration, il y aura un problème de sauts de ligne incohérents.

Git peut en fait gérer lui-même le problème des sauts de ligne incohérents, mais il peut produire des résultats inattendus. Il est donc nécessaire d’effectuer les réglages pertinents. Généralement, si vous ne voulez pas vous embêter, vous pouvez utiliser les méthodes courantes, comme indiqué ci-dessous :

$ git config --global core.autocrlf true

En fait, lorsque vous avez installé la version Windows de git ou togoiseGit, vous avez peut-être déjà fait une telle configuration, peut-être ne la saviez-vous pas à l'époque, par exemple, la raison pour laquelle l'affiche a généré un tel avertissement :

Attention : LF sera remplacé par CRLF dans...

trueC'est parce que vous avez effectué la configuration ci-dessus. Quant à la raison pour laquelle il est coincé là, c'est peut-être parce qu'il y a trop d'endroits à remplacer. Peut-être que vous pouvez simplement attendre patiemment un moment. À propos, si vous remplacez false par

, vous laissez git le gérer tout seul, donc aucun avertissement n'est signalé. Cela ne résout pas fondamentalement le problème. Cela peut provoquer des sauts de ligne entre vous et vos amis. unifié.

.gitattributesBien sûr, il existe une meilleure façon de résoudre le problème des sauts de ligne incohérents : utilisez .gitignore pour unifier les sauts de ligne dans les fichiers. Ce fichier est quelque peu similaire à

. Non seulement les noms sont similaires, mais la syntaxe d'utilisation et d'écriture est également similaire.

Ce fichier doit être situé dans le répertoire racine de l'entrepôt et peut être modifié et soumis comme les autres fichiers. Voici comment écrire ce fichier :

Le contenu du fichier ressemble à un tableau, divisé en deux colonnes : la colonne de gauche est le nom de fichier auquel git doit correspondre ; la colonne de droite est le format de nouvelle ligne que git doit utiliser. Jetons un coup d'œil à une châtaigne :

# 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

.gitignoreSi vous connaissez .gitattributes, vous trouverez la colonne de gauche du fichier ci-dessus très familière. Nous n'entrerons pas dans les détails ici. Si vous ne la connaissez pas, veuillez vérifier vous-même les informations pertinentes. La seule différence est que le fichier text a une colonne supplémentaire à droite, comme text eol=crlf, binary, Nous venons de dire que cette colonne sert à définir le format de saut de ligne utilisé par le correspondant. fichier à gauche. Les colonnes de gauche et de droite sont séparées par des espaces. Présentons en détail la syntaxe de la colonne de droite :

• text=auto
  Laissez git gérer le format de nouvelle ligne utilisé par le fichier correspondant à gauche. Il s'agit de l'option par défaut.

• text eol=crlf
  Utilisez uniformément le format de nouvelle ligne CRLF pour les fichiers correspondants sur la gauche. Si LF apparaît dans un fichier, il sera converti en CRLF.

• text eol=lf
  Utilisez uniformément le format de nouvelle ligne LF pour les fichiers correspondants sur la gauche. Si CRLF apparaît dans un fichier, il sera converti en LF.

• binary
  indique à git qu'il ne s'agit pas d'un fichier texte et que les nouvelles lignes qu'il contient ne doivent pas être modifiées. De plus, binary et le symbole -text -diff sont équivalents.

La syntaxe ci-dessus devrait suffire. Si vous êtes intéressé, vous pouvez vérifier vous-même les informations pertinentes, telles que les informations officielles : https://git-scm.com/book/en/v...

D'une manière générale, la deuxième méthode est la meilleure solution, même si elle est plus gênante que la première méthode.

P.S : Organisé en blog : Git gère le problème des sauts de ligne

Answer 2

Vous l'avez fait dans l'autre sens, cela devrait être défini sur true.