git-diff pour ignorer ^ M

Dans un projet où certains fichiers contiennent ^ M comme séparateurs de nouvelle ligne. Différer ces fichiers est apparemment impossible, car gitdiff le voit car le fichier entier n’est qu’une seule ligne.

Comment diffère-t-il de la version précédente?

Existe-t-il une option comme “traiter ^ M comme nouvelle ligne lors de la diffusion”?

prompt> git-diff "HEAD^" -- MyFile.as diff --git a/myproject/MyFile.as b/myproject/MyFile.as index be78321..a393ba3 100644 --- a/myproject/MyFile.cpp +++ b/myproject/MyFile.cpp @@ -1 +1 @@ -import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate \ No newline at end of file +import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate \ No newline at end of file prompt> 

METTRE À JOUR:

maintenant j’ai écrit un script qui vérifie les 10 dernières révisions et convertit CR en LF.

 require 'fileutils' if ARGV.size != 3 puts "a git-path must be provided" puts "a filename must be provided" puts "a result-dir must be provided" puts "example:" puts "ruby gitcrdiff.rb project/dir1/dir2/dir3/ SomeFile.cpp tmp_somefile" exit(1) end gitpath = ARGV[0] filename = ARGV[1] resultdir = ARGV[2] unless FileTest.exist?(".git") puts "this command must be run in the same dir as where .git resides" exit(1) end if FileTest.exist?(resultdir) puts "the result dir must not exist" exit(1) end FileUtils.mkdir(resultdir) 10.times do |i| revision = "^" * i cmd = "git show HEAD#{revision}:#{gitpath}#{filename} | tr '\\r' '\\n' > #{resultdir}/#{filename}_rev#{i}" puts cmd system cmd end 

GitHub suggère que vous ne deviez utiliser \ n comme caractère de nouvelle ligne que dans les repositorys git-managed. Il y a une option pour convertir automatiquement:

 $ git config --global core.autocrlf true 

Bien sûr, il est dit de convertir crlf en lf, tandis que vous voulez convertir cr en lf. J’espère que cela fonctionne toujours…

Et puis convertissez vos fichiers:

 # Remove everything from the index $ git rm --cached -r . # Re-add all the deleted files to the index # You should get lots of messages like: "warning: CRLF will be replaced by LF in ." $ git diff --cached --name-only -z | xargs -0 git add # Commit $ git commit -m "Fix CRLF" 

core.autocrlf est décrit sur la page de manuel .

Développé sous Windows, j’ai rencontré ce problème lors de l’utilisation de git tfs . Je l’ai résolu de cette façon:

 git config --global core.whitespace cr-at-eol 

Cela indique à Git qu’un CR de fin de ligne n’est pas une erreur. En conséquence, ces caractères ^M ennuyeux n’apparaissent plus à la fin des lignes dans git diff , git show , etc.

Il semble laisser les autres parameters tels quels; Par exemple, les espaces supplémentaires à la fin d’une ligne apparaissent toujours comme des erreurs (surlignées en rouge) dans le diff.

(D’autres réponses ont fait allusion à cela, mais ce qui précède est exactement comment définir le paramètre. Pour définir le paramètre pour un seul projet, omettez le --global .)

EDIT :

Après de nombreux problèmes de fin de ligne, j’ai eu la meilleure chance de travailler avec une équipe .NET avec ces parameters:

  • Pas de réglage core.eol
  • Pas de paramètre core.whitespace
  • Pas de paramètre core.autocrlf
  • Lorsque vous exécutez le programme d’installation de Git pour Windows, vous obtenez ces trois options:
    • Checkout style Windows, validez les fins de ligne Unix-style < - choisissez celui-ci
    • Checkout tel quel, validez les fins de ligne de style Unix
    • Checkout tel quel, validez tel quel

Si vous devez utiliser le paramètre d’espacement, vous devez probablement l’activer uniquement par projet si vous devez interagir avec TFS. --global juste le --global :

 git config core.whitespace cr-at-eol 

Si vous devez supprimer certains parameters de base. *, Le plus simple est d’exécuter cette commande:

 git config --global -e 

Cela ouvre votre fichier global .gitconfig dans un éditeur de texte et vous pouvez facilement supprimer les lignes que vous souhaitez supprimer. (Ou vous pouvez mettre ‘#’ devant eux pour les commenter.)

Essayez git diff --ignore-space-at-eol , ou git diff --ignore-space-change , ou git diff --ignore-all-space .

Regarde aussi:

 core.whitespace = cr-at-eol 

ou équivalent,

 [core] whitespace = cr-at-eol 

où les whitespace sont précédés d’un caractère de tabulation .

Pourquoi obtenez-vous ces ^M dans votre git diff ?

Dans mon cas, je travaillais sur un projet qui a été développé sous Windows et j’ai utilisé OS X. Lorsque j’ai modifié du code, j’ai vu ^M à la fin des lignes que j’ai ajoutées dans git diff . Je pense que les ^M apparaissaient parce que les fins de ligne étaient différentes de celles du rest du fichier. Comme le rest du fichier a été développé sous Windows, il utilisait les fins de ligne CR et, dans OS X, il utilisait les fins de ligne LF .

Apparemment, le développeur Windows n’a pas utilisé l’option ” Extraire le style Windows, valider les fins de ligne de type Unix ” lors de l’installation de Git.

Alors, que devrions-nous faire à ce sujet?

Vous pouvez demander aux utilisateurs de Windows de réinstaller git et d’utiliser l’option ” Vérifier les terminaisons de style Unix de style Windows “. C’est ce que je préférerais, car je vois Windows comme une exception dans ses caractères de fin de ligne et Windows corrige son problème de cette manière.

Si vous optez pour cette option, vous devez cependant corriger les fichiers actuels (car ils utilisent toujours les fins de ligne CR ). Je l’ai fait en suivant ces étapes:

  1. Supprimez tous les fichiers du référentiel, mais pas de votre système de fichiers.

     git rm --cached -r . 
  2. Ajoutez un fichier .gitatsortingbutes qui impose certains fichiers pour utiliser un fichier LF comme fins de ligne. Mettez ceci dans le fichier:

     *.ext text eol=crlf 

    Remplacez .ext par les extensions de fichier que vous souhaitez faire correspondre.

  3. Ajoutez à nouveau tous les fichiers.

     git add . 

    Cela affichera des messages comme ceci:

     warning: CRLF will be replaced by LF in . The file will have its original line endings in your working directory. 
  4. Vous pouvez supprimer le fichier .gitatsortingbutes à moins d’avoir des utilisateurs Windows obstinés qui ne souhaitent pas utiliser l’option ” Vérifier les fins de ligne de style Unix “.

  5. S’engager et pousser le tout.

  6. Supprimez et retirez les fichiers applicables sur tous les systèmes sur lesquels ils sont utilisés. Sur les systèmes Windows, assurez-vous qu’ils utilisent désormais l’option ” Vérifier les terminaisons de style Unix de style Windows, valider “. Vous devez également le faire sur le système sur lequel vous avez exécuté ces tâches, car lorsque vous avez ajouté les fichiers, git a déclaré:

     The file will have its original line endings in your working directory. 

    Vous pouvez faire quelque chose comme ça pour supprimer les fichiers:

     git ls | grep ".ext$" | xargs rm -f 

    Et puis ceci pour les récupérer avec les fins de ligne correctes:

     git ls | grep ".ext$" | xargs git checkout 

    Bien sûr, remplacer .ext par l’extension souhaitée.

Maintenant, votre projet utilise uniquement des caractères LF pour les fins de ligne, et les personnages CR méchants ne reviendront jamais :).

L’autre option consiste à appliquer des fins de ligne de style Windows. Vous pouvez également utiliser le fichier .gitatsortingbutes pour cela.

Plus d’infos: https://help.github.com/articles/dealing-with-line-endings/#platform-all

Existe-t-il une option comme “traiter ^ M comme nouvelle ligne lors de la diffraction”?

Il y en aura une avec Git 2.16 (Q1 2018), car la famille de commandes ” diff ” a appris à ignorer les différences de retour chariot à la fin de la ligne.

Voir commit e9282f0 (26 oct. 2017) par Junio ​​C Hamano ( gitster ) .
Aider par: Johannes Schindelin ( dscho ) .
(Fusionné par Junio ​​C Hamano – gitster – dans commit 10f65c2 , 27 nov. 2017)

diff: --ignore-cr-at-eol

Une nouvelle option --ignore-cr-at-eol indique aux machines diff de traiter un retour chariot à la fin d’une ligne (complète) comme si elle n’existait pas.

Tout comme les autres --ignore-*--ignore-* ” pour ignorer divers types de différences d’espaces, cela vous aidera à examiner les changements réels que vous avez apportés sans vous laisser distraire par les fausses conversions CRLF< ->LF effectuées par votre éditeur.

J’ai lutté avec ce problème pendant longtemps. La solution la plus simple consiste à ne pas se soucier des caractères ^ M et à utiliser un outil de traitement visuel qui les gère.

Au lieu de taper:

 git diff   

essayer:

 git difftool   

TL; DR

Remplacez le core.pager par "tr -d '\r' | less -REX" , pas par le code source

C’est pourquoi

Ces pesants ^ M illustrés sont un artefact de la colorisation et du pageur. entrer la description de l'image ici Il est causé par less -R , une option par défaut de gager pager. (Le pager par défaut de git est less -REX )

La première chose à noter est que git diff -b ne montrera pas les changements dans les espaces blancs (par exemple, le \ r \ n vs \ n)

installer:

 git clone https://github.com/CipherShed/CipherShed cd CipherShed 

Un test rapide pour créer un fichier Unix et modifier les fins de ligne ne montre aucun changement avec git diff -b :

 echo -e 'The quick brown fox\njumped over the lazy\ndogs.' > test.txt git add test.txt unix2dos.exe test.txt git diff -b test.txt 

Nous notons que forcer un tube à moins ne montre pas le ^ M, mais activer la couleur et less -R fait:

 git diff origin/v0.7.4.0 origin/v0.7.4.1 | less git -c color.ui=always diff origin/v0.7.4.0 origin/v0.7.4.1 | less -R 

Le correctif est affiché en utilisant un canal pour supprimer le \ r (^ M) de la sortie:

 git diff origin/v0.7.4.0 origin/v0.7.4.1 git -c core.pager="tr -d '\r' | less -REX" diff origin/v0.7.4.0 origin/v0.7.4.1 

Une alternative imprudente consiste à utiliser less -r , car il passera par tous les codes de contrôle, pas seulement les codes de couleur.

Si vous voulez simplement éditer votre fichier de configuration git directement, c’est l’entrée pour mettre à jour / append:

 [core] pager = tr -d '\\r' | less -REX 

Si vous utilisez Eclipse, vous pouvez faire disparaître le ^M de git diff en définissant File > Convert Line Delimiter To > Unix (LF, \n, 0A, ¶)