git-diff игнорировать ^M

в проекте, где некоторые файлы содержат ^M в качестве разделителей новой строки. Разделение этих файлов, по-видимому, невозможно, так как git-diff видит его как весь файл-это всего лишь одна строка.



как один 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>



обновление:



теперь я написал скрипт, который проверяет последние 10 ревизий и преобразует CR в ПЕРЕВОД СТРОКИ.



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
1255   9  

9 ответов:

GitHub предлагает что вы должны убедиться, что используете только \n в качестве символа новой строки в репозиториях с обработкой git. Есть возможность автоматического преобразования:

$ git config --global core.autocrlf true

конечно, это говорит о преобразовании crlf в lf, в то время как вы хотите конвертировать cr в lf. Я надеюсь, что это все еще работает...

а затем конвертировать файлы:

# 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"

ядра.autocrlf описывается на на странице.

275  
2015-12-17 17:39:37

разработки на Windows, я столкнулся с этой проблемой при использовании git tfs. Я решил это так:

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

это в основном говорит Git, что конец строки CR не является ошибкой. В результате те раздражают ^M символы больше не появляются в конце строк в git diff,git show и т. д.

кажется, что он оставляет другие настройки как есть; например, дополнительные пробелы в конце строки все еще отображаются как ошибки (выделенные красным цветом) в diff.

(другие ответы ссылались на это, но выше именно так, как установить настройку. Чтобы задать параметр только для одного проекта, опустите --global.)

EDIT:

после многих страданий, связанных с окончанием строки, Мне повезло, когда я работал в команде .NET, с этими настройками:

  • нет ядра.настройка eol
  • нет ядра.установка пробелов
  • нет ядра.установка autocrlf
  • при запуске установщика Git для Windows, вы получите эти три варианта:
    • проверка Windows-стиль, фиксация Unix-стиль окончания строки
    • проверка как есть, фиксация окончаний строк в стиле Unix
    • проверка как есть, фиксация как есть

Если вам нужно использовать параметр пробела, вы, вероятно, должны включить его только на основе каждого проекта, если вам нужно взаимодействовать с TFS. Просто опустите --global:

git config core.whitespace cr-at-eol

Если вам нужно удалить некоторые ядра.* настройки, самый простой способ-запустить эту команду:

git config --global -e

это открывает ваш глобальный .gitconfig файл в текстовом редакторе, и вы можете легко удалить строки, которые вы хотите удалить. (Или вы можете поставить ' # ' перед ними, чтобы прокомментировать их.)

271  
2012-04-02 23:57:54

попробовать git diff --ignore-space-at-eol или git diff --ignore-space-change или git diff --ignore-all-space.

102  
2009-12-11 20:19:56

Смотрите также:

core.whitespace = cr-at-eol

или

[core]
    whitespace = cr-at-eol

здесь whitespace начинается с tab символ.

90  
2015-02-27 05:07:33

почему вы получаете эти ^M в своем git diff?

в моем случае я работал над проектом, который был разработан в Windows, и я использовал OS X. Когда я изменил какой-то код, я увидел ^M в конце строк я добавил в git diff. Я думаю, что ^M появлялись, потому что они были разными окончаниями строк, чем остальная часть файла. Потому что остальная часть файла была разработана в Windows используется CR окончания строк, и в OS X он использует LF линия окончания.

по-видимому, разработчик Windows не использовал опцию"проверка в стиле Windows, фиксация окончаний строк в стиле Unix " во время установки Git.

так что же нам с этим делать?

вы можете заставить пользователей Windows переустановить git и использовать "проверка в стиле Windows, фиксация окончаний строк в стиле Unix опции". Это то, что я бы предпочел, потому что я вижу окна как исключение в его конце строки персонажи и Windows исправляет свою собственную проблему таким образом.

если вы идете на эту опцию, вы должны, однако, исправить текущие файлы (потому что они все еще используют CR концы строк). Я сделал это, выполнив следующие действия:

  1. удалите все файлы из репозитория, но не из вашей файловой системы.

    git rm --cached -r .

  2. добавить .gitattributes файл, который принуждает определенные файлы использовать LF как окончание строки. Положите это в файл:

    *.ext text eol=crlf

    заменить .ext с расширениями файлов, которые вы хотите сопоставить.

  3. добавить все файлы.

    git add .

    это покажет сообщения, как это:

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

  4. убрать .gitattributes файл, если у вас нет упрямых пользователей Windows, которые не хотят использовать "проверка в стиле Windows, фиксация окончаний строк в стиле Unix опции".

  5. совершить и подтолкнуть все это.

  6. удалить и проверить соответствующие файлы на всех системах, где они используются. На системах Windows, убедитесь, что они теперь используют "проверка в стиле Windows, фиксация окончаний строк в стиле Unix опции". Вы также должны сделать это в системе, где вы выполнили эти задачи, потому что при добавлении файлов git сказал:

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

    вы можете сделать что-то подобное, чтобы удалить файлы:

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

    и затем это, чтобы получить их обратно с правильными окончаниями строки:

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

    конечно, заменить .ext С расширением требуется.

теперь ваш проект использует только LF символы окончания строки, и противный CR персонажи никогда не вернутся :).

другой вариант заключается в применении окончаний строк стиля windows. Вы также можете использовать для этого.

больше информация: https://help.github.com/articles/dealing-with-line-endings/#platform-all

31  
2016-12-20 18:36:10

есть ли такая опция, как" лечить ^M как новую строку при различии"?

там будет один с Git 2.16 (Q1 2018), как "diff" семейство команд научилось игнорировать различия в возврате каретки в конце строки.

посмотреть commit e9282f0 (26 окт 2017) by Junio C Hamano (gitster).
Помог-by:Йоханнес Schindelin (dscho).
(слитый Junio C Hamano -- gitster-- на commit 10f65c2, 27 ноября 2017)

diff:--ignore-cr-at-eol

новый параметр --ignore-cr-at-eol сообщает diff machinery для обработки возврата каретки в конце (полной) строки, как будто ее не существует.

так же, как и другие "--ignore-*" опции для игнорирования различных видов пробелов различия, это поможет рассмотреть реальные изменения, которые вы сделали, не отвлекаясь на поддельные CRLF<->LF преобразование, выполненное вашей редакторской программой.

14  
2018-05-15 14:03:24

TL; DR

изменить core.pager до "tr -d '\r' | less -REX", а не исходный код

вот почему

эти надоедливые ^M показаны артефакт раскрашивания и пейджера. enter image description here Это вызвано less -R, опция git пейджера по умолчанию. (git по умолчанию пейджер less -REX)

первое, что нужно отметить, что git diff -b не будет показывать изменения в белом пространстве (например, \r \ n vs \n)

настройка:

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

быстрый тест для создания файла unix и изменения окончаний строк не покажет никаких изменений с 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

мы отмечаем, что принуждение трубы к меньшему не показывает ^M, но позволяет цвет и less -R тут:

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

исправление показано с помощью трубы для удаления \r (^M) с выхода:

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

неразумная альтернатива-использовать less -r, потому что это пройдет через все управляющие коды, а не только цветовые коды.

если вы хотите просто отредактировать файл конфигурации git напрямую, это запись для обновления / добавления:

[core]
        pager = tr -d '\r' | less -REX
11  
2017-09-17 17:19:36

Я долго боролся с этой проблемой. Безусловно, самое простое решение-не беспокоиться о символах ^M и просто использовать визуальный инструмент diff, который может их обрабатывать.

вместо ввода:

git diff <commitHash> <filename>

попробуй:

git difftool <commitHash> <filename>
10  
2011-08-16 07:10:44

Если вы используете Eclipse, вы можете сделать ^M исчезают из git diff установка File > Convert Line Delimiter To > Unix (LF, \n, 0A, ¶)

0  
2015-12-04 15:48:08

Comments

    Ничего не найдено.
Click here to cancel reply.