Слияние изменений поддерева - фатальный: недопустимый путь 'somefile_BASE_20704.cs'

У меня есть три репозиции - имена изменены для ясности:

SharedStuff, ProjectA и ProjectB

Оба проекта используют git -subtree для сохранения локальной копии SharedStuff. Они оба внесли локальные изменения, которые я пытаюсь объединить централизованно, тестировать, а затем снова сливаться с каждым.

Я запустил это в репозитории ProjectA:

git subtree split --prefix=SharedStuff -b SharedStuff_from_ProjectA --rejoin

... затем перетащил его в репозиторий SharedStuff, разрешил несколько простых конфликтов, объединил его.

Теперь я запустил это в репозитории ProjectB:

git subtree split --prefix=platform/SharedStuff -b SharedStuff_from_Project_B --rejoin

... и снова нажал на SharedStuff repo в новой ветке. Проблема возникает, когда я пытаюсь объединить эти изменения.

В текущем случае я переключаюсь на ветвь SharedStuff_from_Project_B, затем git merge master - но сразу получаю все измененные файлы, перечисленные как конфликты добавить/добавить. Когда я запускаю git mergetool, каждый из них имеет такую ошибку:

Merging:
somefile.xyz

Normal merge conflict for 'somefile.xyz':
  {local}: created file
  {remote}: created file
fatal: invalid path './somefile.xyz_BASE_20704.cs'

(Конечно, если я попробую наоборот - объединить SharedStuff_from_Project_B в master - я получаю одни и те же конфликты, просто обратный. Еще добавьте/добавьте).

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

Изменить: в ProjectB было добавлено предыдущее поддерево "rejoin" commit, но изменения в нем не были объединены в SharedStuff. Но при повторном запуске git subtree split с --ignore-joins возникает одна и та же проблема - много конфликтов слияния add/add, несмотря на историю этой ветки разделяющего поддерева, возвращающейся обратно, когда SharedStuff был сначала помещен в ProjectB.: (

Изменить: также git merge-base между разделенным поддеревом от ProjectB и master на SharedStuff не дает никаких результатов. Я не уверен, как это произошло или как решить?

Ответ 1

Я не знаю, что вызвало это. Однако вот как я это разрешил - вроде как. Мне все еще нужны лучшие ответы!

Обе "общие" ветки фактического мастера на SharedStuff, а разделенная копия из ProjectB имела то же самое в своей отдаленной истории - ну, те же самые изменения с теми же самыми tree SHA внутри, но различные фиксированные SHA. Это связано с тем, что ветвь ProjectB имела, по крайней мере, первую начальную фиксацию, отличную от SharedStuff.

Пока в истории не было общих коммитов (с теми же самыми SHA), слияние, перезагрузка и т.д. не смогут найти общий язык и предполагают, что файлы были добавлены в обеих историях.

Решение: найдите две ранние фиксации в истории с тем же tree SHA (т.е. точно таким же содержимым файла) и зафиксируйте информацию - сообщение, автора и т.д. - и вручную перепишите родителя этого коммита в ProjectB разделить ветвь на родительский объект в SharedStuff master.

Я сделал это с помощью трансплантата: Установка родительского указателя git для другого родителя

Напишите новую строку .git/info/grafts, в основном wrong-parent right-parent
Переключиться на ветку - обнаружить PowerShell echo использовать 16-битный формат символа, перезаписать с помощью Sublime Text и снова переключиться;)
Запустите git filter-branch right-parent..HEAD на ветке, чтобы запечатать сделку.
Проверить все слияние

Следующая интересная задача - увидеть, как эта версия сливается обратно в ProjectB; будет обновляться, когда это будет сделано.

Я бы все же действительно приветствовал реальный ответ на этот вопрос - это действительно взломано!