Lorsque vous utilisez tortoisegit pour soumettre un projet, LF sera remplacé par CRLF dans...
迷茫
迷茫 2017-05-02 09:49:01
0
2
954

Lors de la soumission du projet, un tas d'avertissements sont apparus : LF sera remplacé par CRLF dans..., et j'étais coincé à mettre à jour l'index. J'étais sur le point de le soumettre. J'ai vérifié en ligne et j'ai découvert qu'il s'agissait d'une ligne. problème de casse. La solution était <🎜 > Cela peut être résolu, mais cela ne fonctionne pas ici pour moi. Je ne sais pas quel est le problème. Quelqu'un peut-il m'aider à le vérifier ? Voici le contenu dans la configuration git config --global core.autocrlf false

迷茫
迷茫

业精于勤,荒于嬉;行成于思,毁于随。

répondre à tous(2)
漂亮男人

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

为情所困

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

Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal