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

En quoi diffère-t-on de la version précédente?

Existe-t-il une option comme "traiter ^ M comme un saut de ligne en cas de différence"?

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 @@
-<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
+<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
prompt>

MISE À JOUR:

maintenant j'ai écrit un script Ruby 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 devez vous assurer d'utiliser uniquement \ n comme caractère de nouvelle ligne dans les dépôts git. Il existe une option de conversion automatique:

$ git config --global core.autocrlf true

Bien sûr, cela est censé 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 <file>."
$ 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 .

En développant sur Windows, j'ai rencontré ce problème lors de l'utilisation git tfs. Je l'ai résolu de cette façon:

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

Cela indique essentiellement à Git qu'un CR de fin de ligne n'est pas une erreur. En conséquence, ces ennuyeux ^Mpersonnages ne semblent plus à la fin des lignes git diff, git showetc.

Il semble laisser les autres paramètres 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.)

MODIFIER :

Après de nombreux essais de fin de ligne, j'ai eu la meilleure chance, lorsque je travaillais sur une équipe .NET, avec ces paramètres:

• AUCUN paramètre core.eol
• AUCUN paramètre core.whitespace
• AUCUN paramètre core.autocrlf
• Lorsque vous exécutez le programme d'installation de Git pour Windows, vous obtiendrez ces trois options:
  • Extraire le style Windows, valider les fins de ligne de style Unix <- choisissez celui-ci
  • Commander en l'état, valider les fins de ligne de style Unix
  • Commander tel quel, valider tel quel

Si vous devez utiliser le paramètre d'espaces, vous ne devriez probablement l'activer que par projet si vous avez besoin d'interagir avec TFS. Oubliez simplement --global:

git config core.whitespace cr-at-eol

Si vous devez supprimer certains paramètres de base. *, Le moyen le plus simple consiste à 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ù whitespaceest précédé d'un caractère de tabulation .

Pourquoi les mettez-vous ^Mdans votre git diff?

Dans mon cas, je travaillais sur un projet développé sous Windows et j'ai utilisé OS X. Quand j'ai changé du code, j'ai vu ^Mà la fin des lignes que j'avais ajoutées git diff. Je pense que les ^Mapparaissaient parce que leurs fins de ligne étaient différentes de celles du reste du fichier. Étant donné que le reste du fichier a été développé sous Windows, il a utilisé des CRfins de ligne et sous OS X, il utilise des LFfins de ligne.

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

Alors, que devons-nous faire à ce sujet?

Vous pouvez demander aux utilisateurs de Windows de réinstaller git et d'utiliser l' option " Extraire le style Windows, valider les fins de ligne de style Unix ". 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 propre problème de cette façon.

Si vous optez pour cette option, vous devez cependant corriger les fichiers actuels (car ils utilisent toujours les CRfins de ligne). 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 .gitattributesfichier qui force certains fichiers à utiliser une LFfin de ligne as. Mettez ceci dans le fichier:

   *.ext text eol=crlf
   

   Remplacez .extpar les extensions de fichier que vous souhaitez faire correspondre.

3. Ajoutez à nouveau tous les fichiers.

   git add .
   

   Cela affichera des messages comme celui-ci:

   warning: CRLF will be replaced by LF in <filename>.
   The file will have its original line endings in your working directory.
   

4. Vous pouvez supprimer le .gitattributesfichier sauf si vous avez des utilisateurs Windows tenaces qui ne veulent pas utiliser l' option " Extraire le style Windows, valider les fins de ligne de style Unix ".

5. Engagez-vous et poussez tout.

6. Supprimez et extrayez les fichiers applicables sur tous les systèmes où ils sont utilisés. Sur les systèmes Windows, assurez-vous qu'ils utilisent désormais l' option " Extraire le style Windows, valider les fins de ligne de style Unix ". 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 ceci pour supprimer les fichiers:

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

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

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

   Bien sûr, remplacer .extpar l'extension que vous souhaitez.

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

L'autre option consiste à appliquer les fins de ligne de style Windows. Vous pouvez également utiliser le .gitattributesfichier pour cela.

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

Existe-t-il une option comme "traiter ^ M comme un saut de ligne en cas de différence"?

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

Voir commit e9282f0 (26 octobre 2017) de Junio ​​C Hamano ( gitster) .
Aidé 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-eolindique à la machine diff de traiter un retour chariot à la fin d'une ligne (complète) comme s'il n'existait pas.

Tout comme les autres --ignore-*options " " pour ignorer les différents types de différences d'espaces, cela vous aidera à revoir les modifications réelles que vous avez apportées sans vous laisser distraire par une CRLF<->LFconversion parasite effectuée par votre programme d'édition.

TL; DR

Changez le core.pageren "tr -d '\r' | less -REX", pas le code source

C'est pourquoi

Ces embêtants ^ M illustrés sont un artefact de la colorisation et du téléavertisseur. Elle est causée par less -Rune option de pager git par défaut. (le pager par défaut de git est less -REX)

La première chose à noter est que git diff -bcela 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 montrera 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 tuyau à moins n'affiche pas le ^ M, mais active la couleur et less -Rfait:

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 indiqué en utilisant un tuyau 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 à l'utiliser less -r, car elle passera par tous les codes de contrôle, pas seulement les codes de couleur.

Si vous souhaitez simplement modifier directement votre fichier de configuration git, voici l'entrée à mettre à jour / ajouter:

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

J'ai lutté avec ce problème pendant longtemps. De loin, la solution la plus simple est de ne pas se soucier des caractères ^ M et d'utiliser simplement un outil de diff visuel qui peut les gérer.

Au lieu de taper:

git diff <commitHash> <filename>

essayer:

git difftool <commitHash> <filename>

Dans mon cas, qu'est-ce que c'était cette commande:

git config  core.whitespace cr-at-eol

Source: https://public-inbox.org/git/8d7e4807-9a79-e357-8265-95f22ab716e0@web.de/T/

Comme indiqué par VonC, cela a déjà été inclus dans git 2.16+. Malheureusement, le nom de l'option ( --ignore-cr-at-eol) diffère de celui utilisé par GNU diff auquel je suis habitué ( --strip-trailing-cr).

Lorsque j'ai été confronté à ce problème, ma solution était d'appeler GNU diff au lieu du diff intégré de git, car mon git est plus ancien que 2.16. Je l'ai fait en utilisant cette ligne de commande:

GIT_EXTERNAL_DIFF='diff -u --strip-trailing-cr "$2" "$5";true;#' git diff --ext-diff

Cela permet d'utiliser --strip-trailing-cret toutes les autres options de diff GNU.

Il y a aussi cette autre façon:

git difftool -y -x 'diff -u --strip-trailing-cr'

mais il n'utilise pas les paramètres de pager configurés, c'est pourquoi je préfère le premier.