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

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

10 голосов
/ 31 марта 2012

У меня есть проект, который был запущен в 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 по-прежнему показывает десятки подобных файлов, которые кажутся идентичными. Я не знаю, как решить эту проблему.

Ответы [ 4 ]

9 голосов
/ 31 марта 2012

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

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

5 голосов
/ 14 апреля 2012

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

1 голос
/ 20 февраля 2015

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

1 голос
/ 11 июня 2012

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

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

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

...