git-diff à ignorer ^M
Dans un projet où certains des fichiers contient des ^M que le saut de ligne séparateurs. Comparaison de ces fichiers sont apparemment impossible, depuis git-diff voit que le fichier entier est une seule ligne.
Comment un diff avec la version précédente?
Est-il une option comme "traiter ^M que de retour à la ligne lors de la comparaison" ?
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 qui vérifie les 10 dernières révisions et les convertit en CR à 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
- vous avez peut-être voulu
git diff -b
- j'ai montré dans ce stackoverflow.com/a/46265081/58794 - Avec Git 2.16 (T1 2018), vous aurez
git diff --ignore-cr-at-eol
. Voir ma réponse ci-dessous. - et pour les futurs Googlers: j'ai dû chercher les
git diff -b
est identique àgit diff --ignore-space-change
.
Vous devez vous connecter pour publier un commentaire.
GitHub suggère que vous devriez assurez-vous d'utiliser uniquement \n comme un caractère de saut de ligne dans git-traitées repos. Il y a une option de conversion automatique:
Bien sûr, ce qui est dit pour convertir crlf à la fl, alors que vous voulez convertir cr à lf. J'espère que cela fonctionne encore ...
Puis convertir vos fichiers:
de base.autocrlf est décrit sur la page de man.
git config core.whitespace cr-at-eol
.warning: LF will be replaced by CRLF
au lieu dewarning: CRLF will be replaced by LF
, et je suis sous Linux. Aucune idée pourquoi? Je veux tout à la fin, avec LF, pas CRLF!git config --global core.autocrlf input
, effectuez les étapes de cette réponse(rm, ajouter, s'engager), et vous obtiendrezwarning: CRLF will be replaced by LF. The file will have its original line endings in your working directory.
. Supprimer les fichiers (parce qu'ils ont l'original, mal CRLF) et la caisse de nouveau à partir de la dernière "Fix CRLF" s'engager.rm .git/index && git reset
de commande.Développement sur Windows, j'ai rencontré ce problème lors de l'utilisation de
git tfs
. Je l'ai résolu de cette façon:En fait cela indique à Git que d'une fin de ligne CR n'est pas une erreur. En conséquence, ces ennuyeux
^M
caractères n'apparaissent plus à la fin de lignes engit diff
,git show
, etc.Il semble laisser les autres paramètres comme, par exemple, des espaces supplémentaires à la fin d'une ligne est-il toujours des erreurs (surligné en rouge) dans le diff.
(D'autres réponses ont fait allusion à cela, mais le dessus est exactement la façon de définir le paramètre. Pour définir le paramètre pour un seul projet, omettre le
--global
.)MODIFIER:
Après de nombreux la ligne de fin de travaux, j'ai eu la meilleure chance, lorsque vous travaillez sur un .NET de l'équipe, avec ces paramètres:
Si vous avez besoin d'utiliser l'espace de configuration, vous devriez probablement l'activer uniquement sur une base par projet si vous avez besoin d'interagir avec TFS. Omettez simplement le
--global
:Si vous avez besoin de supprimer certains de base.* paramètres, le plus simple est d'exécuter cette commande:
S'ouvre dans votre global .gitconfig fichier dans un éditeur de texte, et vous pouvez facilement supprimer les lignes que vous souhaitez supprimer. (Ou vous pouvez mettre '#' devant eux pour les mettre en commentaires.)
core.autocrlf
àtrue
git config --global core.whitespace cr-at-eol
désactiver les autres paramètres par défaut. Il y a trois valeurs par défaut: vide-à-eol, vide-à-expressions du folklore et de l'espace-avant-onglet. Afin de permettre la cr-à-eol tout en gardant les autres, vous devez utilisergit config --global core.whitespace blank-at-eol,blank-at-eof,space-before-tab,cr-at-eol
.cr-at-eol
se débarrasser de^M
à la fin de lignes engit diff
tout droit, mais GIT encore montré ces lignes différentes, bien que la fin de ligne est la seule différence.git help config
.Essayer
git diff --ignore-space-at-eol
, ougit diff --ignore-space-change
, ougit diff --ignore-all-space
.autocrlf
paramètres. Merci!less
, ou modifier Git pager. HTHgit diff -w --stat
etgit diff --stat
? L'ancien ne doit pas afficher toutes les modifications si la différence est seulement dans la ^M (c'est à dire CR LF vs LF).Voir aussi:
ou, de manière équivalente,
où
whitespace
est précédée par une onglet caractère.git show
) arrêter m'énerve à propos de la^M
s sur les lignes modifiées! 🙂git diff
montre encore ^M caractères.git config --global core.whitespace cr-at-eol
(où --global est en option si vous voulez juste sur le repo vous êtes sur)[core]
afin que je puisse remplacer lecore.
préfixe avec un caractère de TABULATION.^M
dansgit diff
, pas sur la façon de ne pas les mettre dans les ^M dans la première place. Cela signifie que l'on a accepté la réponse de l'évolution descore.autocrlf
n'est pas le meilleur parce qu'il modifie en silence les fichiers sans que l'utilisateur de la confirmation.Pourquoi avez-vous obtenu ces
^M
dans votregit diff
?Dans mon cas, je travaille sur un projet qui a été développé dans Windows et j'ai utilisé des OS X. Lorsque j'ai modifié le code, j'ai vu
^M
à la fin de la partie que j'ai ajouté dansgit diff
. Je pense que le^M
apparaissaient parce qu'ils étaient différents des fins de ligne que le reste du fichier. Parce que le reste du fichier a été développé sous Windows, c'utiliséCR
les fins de ligne, et dans OS X, il utiliseLF
les fins de ligne.Apparemment, Windows développeur n'a pas à utiliser l'option "la Caisse de style Windows, commettre de style Unix, les fins de ligne" lors de l'installation de Git.
Alors que devons-nous faire à ce sujet?
Vous pouvez avoir les utilisateurs de Windows réinstaller git et d'utiliser le "la Caisse de style Windows, commettre de style Unix, les fins de ligne" option. C'est ce que je préfère, parce que je reportez-vous à Windows en tant qu'exception dans les caractères de fin de ligne et Windows corrige ça de cette façon.
Si vous allez pour cette option, vous devez réparer les fichiers en cours (parce qu'ils sont toujours à l'aide de la
CR
les fins de ligne). Je l'ai fait en suivant ces étapes:De supprimer tous les fichiers dans le dépôt, mais pas à partir de votre système de fichiers.
Ajouter un
.gitattributes
fichier qui impose de certains fichiers pour utiliser unLF
que les fins de ligne. Mettre ceci dans le fichier:Remplacer
.ext
avec les extensions de fichier que vous souhaitez associer.Ajouter de nouveau tous les fichiers.
Cela va afficher les messages comme ceci:
Vous pouvez supprimer le
.gitattributes
fichier, sauf si vous avez têtu les utilisateurs de Windows qui ne veulent pas utiliser le "la Caisse de style Windows, commettre de style Unix, les fins de ligne" option.Commit et push tout.
Supprimer et extraire le fichier qui s'applique sur tous les systèmes où ils sont utilisés. Sur les systèmes Windows, assurez-vous qu'ils utilisent désormais le "la Caisse de style Windows, commettre de style Unix, les fins de ligne" option. Vous devez aussi le faire sur le système où vous avez exécuté ces tâches parce que quand vous avez ajouté les fichiers git dit:
Vous pouvez faire quelque chose comme ceci pour supprimer les fichiers:
Et puis ce de les faire revenir avec la bonne fin de ligne:
Bien sûr remplacer
.ext
avec l'extension que vous souhaitez.Maintenant votre projet utilise uniquement
LF
caractères pour les fins de ligne, et le méchantCR
personnages ne jamais revenir :).L'autre option est de faire respecter le style des fenêtres des fins de ligne. Vous pouvez également utiliser le
.gitattributes
fichier.Plus d'infos:
https://help.github.com/articles/dealing-with-line-endings/#platform-all
View
->Line Endings
et cliquez surUnix
.^M
signifie? Est-ce un windows ou linux saut de ligne? Ou est-ce juste un "différent" de retour à la ligne par rapport aux autres retours à la ligne dans le fichier?Il y en aura un avec Git 2.16 (T1 2018), comme le "
diff
" de la famille de commandes appris à ignorer les différences dans retour chariot à la fin de la ligne.Voir s'engager e9282f0 (26 Oct 2017) par Junio C Hamano (
gitster
).Aidé par: Johannes Schindelin (
dscho
).(Fusionnés par Junio C Hamano --
gitster
-- dans s'engager 10f65c2, le 27 Novembre 2017)git config --global core.autocrlf true
comme dans la accepté de répondre, ce qui répond à l'OP de la question plus directement: "Est-il une option comme "traiter ^M que de retour à la ligne lors de la comparaison" ?'TL;DR
Changer le
core.pager
à"tr -d '\r' | less -REX"
, pas le code sourceC'est pourquoi
Ces satanés ^M indiqués sont un artefact de la colorisation et le pager.
Elle est causée par
less -R
, un défaut git pager option. (git par défaut du pager estmoins -REX
)La première chose à noter est que
git diff -b
ne sera pas montrer les changements dans l'espace blanc (par exemple, le \r\n vs \n)de l'installation:
Un test rapide pour créer un fichier de type unix et changement de fins de ligne ne montrent pas de changements avec
git diff -b
:Nous notons que le fait de forcer une pipe à moins de ne pas montrer le ^M, mais l'activation de la couleur et de
less -R
n':La correction est présentée à l'aide d'une pipe à la bande \r (^M) à partir de la sortie:
Pas une bonne alternative est d'utiliser
less -r
, car il sera de passer à travers tous les codes de contrôle, non seulement les codes de couleur.Si vous souhaitez simplement modifier votre git config fichier directement, c'est l'entrée de mise à jour/ajouter:
\r\n
les fins de ligne, et certains avaient\n
les fins de ligne (je ne sais pas si c'est pertinent); des diff de l'ancien a montré la^M
dans les lignes modifiées (qui est, le+
lignes).core.autocrlf
a été mis àtrue
. L'exécution degit config core.pager "tr -d '\r' | less -REX"
se débarrasser de la satanés^M
s. Merci!git diff -b
est ce que je cherchais, mais j'apprécie l'explication approfondie.J'ai du mal avec ce problème depuis longtemps. De loin la solution la plus simple est de ne pas s'inquiéter de la ^M caractères et il suffit d'utiliser un visual diff outil qui peut les manipuler.
Au lieu de taper:
essayer: