Использование .gitattributes в качестве стратегии слияния в подмодулях

Question

У меня есть две основные ветви, у которых есть один подмодуль, но указывающий на две разные ветви этого подмодуля.

Что я хочу, так это игнорировать любые изменения субмодуля при слиянии / перебазировании между двумя основными ветвями.

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

В настоящее время у меня internal merge=ours в .gitattributes, но он не работает, он не может объединить подмодуль internal.

Есть ли другая стратегия слияния, которую я могу применить для своих нужд? Или я что-то не так делаю в .gitattributes использовании?

Answer 1

Подмодули записываются в суперпроект как запись gitlink . В gitlink хранится необработанный хэш-идентификатор, который Git-суперпроект будет использовать для команды подмодуля Git на git checkout в подмодуле. (Помимо gitlink, вам также необходимо содержимое файла .gitmodules для предоставления дополнительной информации, необходимой для начального клона, но после того, как клон произошел, эти данные переместились из файла .gitmodules в конфигурацию вашего суперпроекта. Так что .gitmodules содержание становится неактуальным: имеет значение только gitlink.)

Драйвер слияния сообщает Git, как объединять файлы . Запись gitlink не является файлом, поэтому драйверы слияния здесь не действуют. Когда Git объединяет три коммита - базу слияния и две подсказки ветвления - и базу слияния, и две подсказки ветвления имеют разные хеш-идентификаторы, сохраненные в gitlink, вы получите конфликт слияния, и ничего, что вы сделаете, не разрешит его автоматически , Вы должны вручную разрешить это.