Ответ 1

Обновление 2013:

Более поздние версии git разрешают использование слияния со стратегией recursive и стратегией (-X):

• from Git Слияние и исправление смешанных пространств и вкладок с двумя ветвями:

git merge -s recursive -Xignore-space-at-eol

Но использование "-Xignore-space-change" также возможно

• Fab-V упоминает ниже: <Предварительно > git merge master -s recursive -X renormalize

jakub.g также комментарии, что стратегии работают также с выбором вишни:

git cherry-pick abcd123456 --strategy=recursive --strategy-option=renormalize 

Это работает намного лучше, чем ignore-all-space.

Оригинальный ответ (май 2009 г.)

Патч для игнорирования стиля eol был предложен в June 2007, но он касается только git diff --ignore-space-at-eol, а не git merge.

В то время вопрос был запрошен:

Должна ли --ignore-space-at-eol опция git-merge?
Слияния - вот где эта функциональность имеет значение.
Какова семантика слияния с автоматическим разрешением с этими действующими параметрами - используются ли они только для обнаружения переименования, или мы, например, не конфликтуем с конфликтами только с переменными пробелов? И если мы этого не делаем, какую версию мы принимаем автоматически?

Хулио С Хамано не был в восторге:

Это, конечно, соблазнительно, но я подозреваю, что его следует оставить на более поздние раунды.
Я подозреваю, что он представит концепцию двух разных видов различий, один из которых будет механически обработан (т.е. Использовать в слиянии с "git -merge-recursive" и применять с "git -am" ), а другой - для проверки людьми. Часто бывает полезно выполнить ввод данных для последнего случая, даже если результат сравнения помеченных входных файлов может быть легко использован для механического применения.

Общая идея, когда дело доходит до git merge, заключается в том, чтобы полагаться на сторонний инструмент слияния.

Например, я установил DiffMerge как инструмент для git merge, установив набор правил которые позволяют этому инструменту слияния игнорировать eol для определенных типов файлов.

Настройка в Windows с MSysGit1.6.3 для сеанса DOS или git bash с помощью DiffMerge или KDiff3:

• установите каталог в PATH (здесь: c:\HOMEWARE\cmd).
• добавьте в этот каталог script merge.sh(обертка для вашего любимого инструмента слияния)

merge.sh:

#!/bin/sh

# Passing the following parameters to mergetool:
#  local base remote merge_result

alocal=$1
base=$2
remote=$3
result=$4

if [ -f $base ]
then
    #"C:/Program Files/SourceGear/DiffMerge/DiffMerge.exe" "$alocal" "$base" "$remote" -m --result="$result" --title1="Mine" --title2="Merging to: $result" --title3="Theirs"

    # for merge respecting eol, KDiff3 is better than DiffMerge (which will always convert LF into CRLF)
    # KDiff3 will display eol choices (if Windows: CRLF, if Unix LF)
    "C:/Program Files/KDiff3/kdiff3.exe" -m "$base" "$alocal" "$remote" -o "$result"
else
    #there is not always a common ancestor: DiffMerge needing 3 files, BASE will be the result
    #"C:/Program Files/SourceGear/DiffMerge/DiffMerge.exe" "$alocal" "$result" "$remote" -m --result="$result" --title1="Mine" --title2="Merging to: $result" --title3="Theirs"

    # KDiff3 however does know how to merge based on 2 files (not just 3)
    "C:/Program Files/KDiff3/kdiff3.exe" -m "$base" "$remote" -o "$result"
fi

• Объявите свою оболочку слияния для Git

Git команды конфигурации:

git config --global merge.tool diffmerge
git config --global mergetool.diffmerge.cmd "merge.sh \"$PWD/$LOCAL\" \"$PWD/$BASE\" \"$PWD/$REMOTE\" \"$PWD/$MERGED\"
git config --global mergetool.diffmerge.trustExitCode false
git config --global mergetool.diffmerge.keepBackup false

• Убедитесь, что autoCRLF false

Git config на системном уровне:

git config ---system core.autoCRLF=false

• Проверьте, что, когда две строки идентичны (но их символы eol), оба DiffMerge или KDiff3 будут игнорировать эту строку во время слияния.

DOS script (примечание: команда dos2unix приходит отсюда и используется для имитации стиля UNIX-eol. был скопирован в каталог, упомянутый в начале этого ответа.):

В этот момент (нажатие "return" ) откроется DiffMerge или KDiff3, и вы сами увидите, какие линии фактически объединены, а какие строки игнорируются.

Предупреждение: файл результатов всегда будет находиться в режиме Windows eol (CRLF) с помощью DiffMerge...
KDiff3 предлагает сохранить так или иначе.

Ответ 2

Я искал тот же ответ, и я узнал this

Объединение ветвей с различными атрибутами проверки/проверки

Если вы добавили атрибуты к файлу, которые вызывают каноническое формат репозитория для изменения этого файла, например, добавление фильтр очистки/размытия или атрибуты text/eol/ident, слияние чего-либо где атрибут не на месте, обычно вызывает слияние конфликты.

Чтобы предотвратить эти ненужные конфликты слияния, git может быть предложено запустить виртуальный выезд и регистрация всех трех этапов файла, когда разрешая трехстороннее слияние, установив merge.renormalize переменная конфигурации. Это предотвращает изменения, вызванные регистрацией преобразование из вызывающих ложных конфликтов слияния при преобразовании файла сливается с непревращенным файлом.

До тех пор, пока "smudge → clean" приводит к тому же выводу, что и "чистый", даже если файлы уже смазаны, эта стратегия будет автоматически разрешает все связанные с фильтрами конфликты. Фильтры, которые делают не действуют таким образом, могут вызывать дополнительные конфликты слияния, которые должны быть разрешено вручную.

Итак, запуск этой команды в любом репозитории сделает трюк:

git config merge.renormalize true

Ответ 3

После чтения fooobar.com/questions/4817/... и fooobar.com/questions/4817/...

для меня эта команда отлично сделала трюк:

git merge master -s recursive -X renormalize

Ответ 4

Как в этом ответе: fooobar.com/questions/6463/...

Вы можете попробовать: git merge -s recursive -Xignore-space-at-eol

Ответ 5

То, что я сделал, это оставить все по умолчанию (т.е. autocrlf = true), коснуться всех файлов (find. -exec touch {} \;), позволить git видеть их как "измененные" и передавать их обратно, а также с этим. В противном случае вы всегда будете страдать от раздражающих сообщений или неожиданных различий или должны отключить все git пробельные функции.

Вы потеряете информацию о вине, но лучше сделать это раньше, чем позже:)

Ответ 6

"git merge -Xrenormalize" работает как шарм.

Ответ 7

Не похоже, что это можно сделать напрямую, но этот пост предлагает работу.

http://osdir.com/ml/git/2009-02/msg02532.html

Ответ 8

http://stahlforce.com/dev/index.php?tool=remcrlf

Я попробовал, но если после последней строки вашего кода у вас еще нет CRLF, он добавляет сам LF, и файл выглядит измененным в git. Помимо этого он работает.

Ответ 9

Теперь мне кажется, что лучший способ - нормализовать окончания строк на обеих ветвях (и совершить) до их объединения.

Я googled "конвертировать crlf в lf" и нашел это в качестве первых результатов:
http://stahlforce.com/dev/index.php?tool=remcrlf

Я загрузил его и использовал, кажется хорошим инструментом.

>sfk remcr . .py

Обязательно укажите каталог и тип файла (например .py), иначе он может попытаться испортить содержимое каталога .git!

Ответ 10

AFAICT (я не пробовал), вы можете использовать git diff для сравнения ветки, которую хотите объединить с общим предком, а затем применить результаты с помощью git apply. Обе команды имеют опции --ignore-whitespace, чтобы игнорировать ошибки окончания строки и ошибки пробела.

К сожалению, если исправление не применяется чисто, вся операция прерывается. Вы не можете исправить конфликты слияния. Существует опция --reject, позволяющая оставить неуправляемые куски в файлах .rej, что помогает, но не совпадает с конфликтами слияния, показанными в одном файле.

Ответ 11

После чтения Разрешить конфликты слияния: принудительно перезаписать все файлы

Я наконец решил мою версию этой проблемы. Я пытался вытащить обновления из восходящего репо, но мой текущий имел проблемы, связанные с CRLF, и не смог слить в качестве результата. Следует отметить, что у меня не было ЛОКАЛЬНЫХ ИЗМЕНЕНИЙ, о которых мне нужно было беспокоиться. Следующие шаги решили мою проблему:

В соответствии с инструкциями github по синхронизации вилок (https://help.github.com/articles/syncing-a-fork/):

• git fetch upstream

• git reset --hard upstream/master
  Мое ограниченное понимание git говорит мне, что это делает то, что я хочу, - сворачивая свою вилку (без фактических незафиксированных изменений), чтобы получить все изменения, внесенные в исходный источник. Согласно исходной странице, этот шаг обычно не требуется, но проблема CRLF потребовала.

• git merge upstream/master

• git push

Ответ 12

однако я предлагаю использовать такой инструмент, как sed, для достижения правильных окончаний строк, а затем файлов diff. Я провел пару часов в разных проектах с различными окончаниями линии.

Лучший способ:

• копировать только файлы проекта (опустить каталог .git) в другой каталог, создавать в нем репозиторий, затем добавлять файлы и фиксировать их (должно быть на главной ветке в новом репозитории).
• копировать файлы из второго проекта в одну и ту же папку, но другую ветку, например dev (git checkout -b dev), фиксировать файлы в этой ветки и запускать (если первый проект находится в главном):      git diff master..dev --names-only для просмотра только имен измененных файлов