В проекте, где некоторые файлы содержат ^ M в качестве разделителей новой строки. Различить эти файлы, по-видимому, невозможно, так как git-diff видит это, поскольку весь файл представляет собой одну строку.
Как отличается от предыдущей версии?
Есть ли такая опция, как «трактовать ^ M как перевод строки при изменении»?
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>
ОБНОВИТЬ:
Теперь я написал скрипт на Ruby, который проверяет последние 10 ревизий и преобразует 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
git diff -b
- я показал это в stackoverflow.com/a/46265081/58794git diff --ignore-cr-at-eol
. Смотрите мой ответ ниже .git diff -b
идентичноgit diff --ignore-space-change
.Ответы:
GitHub предлагает вам обязательно использовать \ n в качестве символа новой строки в репозиториях с git-обработкой. Существует возможность автоматического преобразования:
Конечно, говорят, что это конвертирует crlf в lf, а вы хотите конвертировать cr в lf. Я надеюсь, что это все еще работает ...
А затем конвертировать ваши файлы:
core.autocrlf описан на странице руководства .
источник
git config core.whitespace cr-at-eol
.warning: LF will be replaced by CRLF
вместоwarning: CRLF will be replaced by LF
, и я в Linux. Есть идеи почему? Я хочу, чтобы все заканчивалось LF, а не CRLF!git config --global core.autocrlf input
, выполните шаги в этом ответе (rm, add, commit), и вы получитеwarning: CRLF will be replaced by LF. The file will have its original line endings in your working directory.
. Удалите файлы (поскольку они имеют исходный, неправильный CRLF) и извлеките их снова из последнего коммита «Fix CRLF».Разрабатывая на Windows, я столкнулся с этой проблемой при использовании
git tfs
. Я решил это так:Это в основном говорит Git, что CR конца строки не является ошибкой. В результате, эти надоедливые
^M
персонажи больше не будут появляться в конце строки вgit diff
,git show
и т.д.Кажется, чтобы оставить другие настройки как есть; например, дополнительные пробелы в конце строки по-прежнему отображаются как ошибки (выделены красным) в diff.
(В других ответах упоминалось об этом, но выше указано, как именно установить настройку. Чтобы установить настройку только для одного проекта, опустите
--global
.)РЕДАКТИРОВАТЬ :
После многих трудностей, связанных с окончанием строки, мне больше всего повезло при работе в команде .NET с этими настройками:
Если вам нужно использовать параметр пробелов, вам, вероятно, следует включить его только для каждого проекта, если вам нужно взаимодействовать с TFS. Просто опустите
--global
:Если вам нужно удалить некоторые настройки core. *, Самый простой способ - запустить эту команду:
Это откроет ваш глобальный файл .gitconfig в текстовом редакторе, и вы сможете легко удалить строки, которые хотите удалить. (Или вы можете поставить «#» перед ними, чтобы закомментировать их.)
источник
core.autocrlf
дляtrue
git config --global core.whitespace cr-at-eol
отключит другие настройки, которые по умолчанию. Существует три значения по умолчанию: blank-at-eol, blank-at-eof и пробел перед вкладкой. Таким образом, чтобы включить cr-at-eol, оставив другие, которые вам нужно использоватьgit config --global core.whitespace blank-at-eol,blank-at-eof,space-before-tab,cr-at-eol
.cr-at-eol
избавился от^M
конца строк вgit diff
целом, но GIT по-прежнему показывал эти строки как разные, хотя окончание строки было единственным отличием.Попробуй
git diff --ignore-space-at-eol
, илиgit diff --ignore-space-change
, илиgit diff --ignore-all-space
.источник
autocrlf
настройки. Спасибо!Также см:
или эквивалентно,
где
whitespace
предшествует символ табуляции .источник
git show
) перестать беспокоить меня о^M
s на измененных строках! :)git diff
по-прежнему показывает ^ M символов.git config --global core.whitespace cr-at-eol
(где --global необязателен, если вы просто хотите, чтобы он был в репо, на котором вы находитесь)[core]
чтобы я мог заменитьcore.
префикс символом TAB.^M
вgit diff
, а не о том , как не ставить в ^ М , в первую очередь. Это означает, что принятый ответ об измененииcore.autocrlf
не самый лучший, потому что он молча изменяет файлы без подтверждения пользователя.Почему вы получаете это
^M
в своемgit diff
?В моем случае я работал над проектом, который был разработан в Windows, и я использовал OS X. Когда я изменил некоторый код, я увидел
^M
в конце строки, которые я добавилgit diff
. Я думаю, что^M
они появлялись, потому что они имели разные окончания строк, чем остальная часть файла. Поскольку остальная часть файла была разработана в Windows, в нем использовалисьCR
окончания строк, а в OS X -LF
окончания строк.По-видимому, разработчик Windows не использовал опцию « Оформить заказ в стиле Windows, зафиксировать окончания строк в стиле Unix » во время установки Git.
Так что же нам с этим делать?
Вы можете попросить пользователей Windows переустановить git и использовать опцию « Оформить заказ в стиле Windows, зафиксировать окончания строк в стиле Unix ». Это то, что я бы предпочел, потому что я вижу Windows как исключение в символах окончания строки, и Windows исправляет свою проблему таким образом.
Если вы выберете эту опцию, вы должны исправить текущие файлы (потому что они все еще используют
CR
окончания строк). Я сделал это, выполнив следующие действия:Удалите все файлы из хранилища, но не из вашей файловой системы.
Добавьте
.gitattributes
файл, который заставляет определенные файлы использовать вLF
качестве окончания строки. Поместите это в файл:Замените
.ext
расширения файлов, которые вы хотите соответствовать.Добавьте все файлы еще раз.
Это покажет такие сообщения:
Вы можете удалить
.gitattributes
файл, если у вас нет упрямых пользователей Windows, которые не хотят использовать " опцию Оформлять заказ в стиле Windows, фиксировать окончания строк в стиле Unix ».Зафиксируйте и продвигайте все это.
Удалите и извлеките соответствующие файлы во всех системах, где они используются. В системах Windows убедитесь, что теперь они используют опцию « Оформлять заказ в стиле Windows, фиксировать окончания строк в стиле Unix ». Вы должны также сделать это в системе, где вы выполняли эти задачи, потому что, когда вы добавляли файлы, git сказал:
Вы можете сделать что-то вроде этого, чтобы удалить файлы:
И затем это, чтобы вернуть их с правильными окончаниями строки:
Конечно замена
.ext
на расширение, которое вы хотите.Теперь ваш проект использует только
LF
символы для окончания строк, и противныеCR
символы никогда не вернутся :).Другим вариантом является принудительное завершение окон в стиле окон. Вы также можете использовать
.gitattributes
файл для этого.Дополнительная информация: https://help.github.com/articles/dealing-with-line-endings/#platform-all
источник
View
->Line Endings
и нажать наUnix
.^M
значит? Это новая строка для Windows или Linux? Или это просто "другая" новая строка по сравнению с другими новыми строками в файле?git config --global core.autocrlf true
- это перебор, а анти-Windows / анти-CR
кампания кажется касательной к этому вопросу.Будет один с Git 2.16 (Q1 2018), так как «
diff
» семейство команд научилось игнорировать различия в возврате каретки в конце строки.См. Коммит e9282f0 (26 октября 2017 г.) Джунио С. Хамано (
gitster
) .Помогает: Йоханнес Шинделин (
dscho
) .(Объединено Junio C Hamano -
gitster
- в коммите 10f65c2 , 27 ноября 2017 г.)источник
git config --global core.autocrlf true
как в принятом ответе, это отвечает на вопрос ОП более прямо: «Есть ли такая опция, как« трактовать ^ M как новую строку при рассчете »?git version 2.20.1 (Apple Git-117)
но добавление ответа core.pager Джейсона Пиерона исправило его. YMMV очевидно.TL; DR
Изменение
core.pager
к"tr -d '\r' | less -REX"
, а не исходный кодВот почему
Эти показные ^ M являются артефактом раскрашивания и пейджера. Это вызвано
less -R
параметром git pager по умолчанию. (Git по умолчанию пейджерless -REX
)Первое, что нужно отметить, это то, что
git diff -b
что не будут отображаться изменения в пустом пространстве (например, \ r \ n vs \ n)настроить:
Быстрый тест для создания файла Unix и изменения концов строк не покажет изменений с
git diff -b
:Мы отмечаем, что при принудительном использовании pipe к параметру less не отображается ^ M, но
less -R
включается цвет и отображается :Исправление показано с помощью канала для удаления \ r (^ M) из вывода:
Неразумной альтернативой является использование
less -r
, потому что оно пройдет через все управляющие коды, а не только цветовые коды.Если вы хотите просто отредактировать файл конфигурации git напрямую, это запись для обновления / добавления:
источник
\r\n
окончания строк, а у некоторых -\n
окончания строк (я не знаю, уместно ли это); различия первых показали^M
в измененных строках (то есть в+
строках).core.autocrlf
был установлен вtrue
. Бегgit config core.pager "tr -d '\r' | less -REX"
избавился от надоедливых^M
с. Спасибо!git diff -b
это то, что я искал, но я ценю подробное объяснение.[core]
раздела файла git «config» путем добавленияpager = tr -d '\\r' | less -REX
было единственным ответом, который работал для меня. Спасибо!Я долго боролся с этой проблемой. Безусловно, самое простое решение - не беспокоиться о символах ^ M и просто использовать визуальный инструмент сравнения, который может их обработать.
Вместо ввода:
пытаться:
источник
В моем случае, что это была за команда:
Источник: https://public-inbox.org/git/8d7e4807-9a79-e357-8265-95f22ab716e0@web.de/T/
источник
Как отмечает VonC, это уже было включено в git 2.16+. К сожалению, имя опции (
--ignore-cr-at-eol
) отличается от имени, используемого в GNU diff, к которому я привык (--strip-trailing-cr
).Когда я столкнулся с этой проблемой, я решил использовать GNU diff вместо встроенного в git diff, потому что мой git старше 2.16. Я сделал это с помощью этой командной строки:
Это позволяет использовать
--strip-trailing-cr
и любые другие опции GNU diff.Есть и другой способ:
но он не использует настроенные параметры пейджера, поэтому я предпочитаю первый.
источник