Почему git показывает конфликт между двумя явно идентичными добавленными файлами?

У меня есть проект, который был запущен в TFS, затем переместился на Git. К сожалению, парень, который перевел его на Git, только что проверял в текущих файлах вместо использования git -tfs. Я пытаюсь переустановить его новые коммиты в Git поверх коммитов, которые я вытащил из TFS, используя git -tfs.

Для этого я просто перезаряжаю свои коммиты поверх git -tfs. (Я понимаю, что это испортит удаленные ветки Git, но мы небольшая команда, и все будет хорошо. Я также попробовал выбор вишни, но я столкнулся с той же проблемой.)

Проблема, с которой я сталкиваюсь, - это набор конфликтов, которые выглядят следующим образом:

<<<<<<< HEAD
namespace OurNiftyProject
{
    public enum CardType
    { 
        Visa = 0,
        MasterCard = 1
    }
}
||||||| merged common ancestors
=======
namespace OurNiftyProject
{
    public enum CardType
    { 
        Visa = 0,
        MasterCard = 1
    }
}
>>>>>>> Add a bunch of stuff.

Похоже, что это конфликт между фиксацией с стороны TFS, которая добавила эти файлы, и фиксацией на стороне Git, которая их добавила (поскольку репозиторий Git запущен пустым).

Логичным было бы пропустить это коммит, возможно, но в нем есть несколько файлов (скажем, десять из пары сотен), которые являются новыми. Конечно, это не вызывает конфликтов.

Почему не может Git самостоятельно определить, что эти два файла идентичны? Даже если я использую --ignore-whitespace, когда я переустанавливаю, Git все еще показывает десятки файлов, подобных этому, которые кажутся одинаковыми. Я не понимаю, как это решить.

Ответы

Ответ 1

Это должно быть о различиях, заканчивающихся окончанием строки, в качестве комментариев ebneter.
Я уже подробно рассказал о том, как слияние git не помогло игнорировать эти различия (в отличие от различий в пробелах):
"Возможно ли, что git -merge проигнорирует разницу в конце строки?

Вот почему для этих хранилищ в гетерогенной среде необходима последовательная политика конверсии eol.
См. "Распределение конфигурации git с кодом".

Ответ 2

Я делаю подобную вещь и только что узнал "-X ignore-space-at-eol". Он доступен для слияния и перезагрузки. Кажется, он делает правильные вещи, но делает это смерть медленной для меня.

Ответ 3

Я только что столкнулся с этой проблемой, после которой этот пост был просто для того, чтобы реализовать для меня сценарий окончания строки.

Итак, FWIW, это произошло в моем случае, потому что я использовал "Использовать окончания строки стиля Windows", но в какой-то момент для другого проекта я переконфигурировал его на "Использовать окончание строк в стиле Unix" (эти конфигурации доступны из программы установки Git).

Возврат к разделу "Использование строк в стиле Windows" разрешил проблему без использования "--ignore-whitespace"

Ответ 4

Если вы можете исключить невидимые изменения из-за разных строк, вы можете проверить, имеют ли файлы разные режимы (например, если установлен исполняемый бит). Git показывает полный файл в diff при изменении режима файла.