Можно ли и нужно ли объединять репозитории на GitHub?

Question

У меня есть встроенный C-проект в довольно старом хранилище с более чем 10-летней историей.Теперь мне нужно перенести весь этот проект на новую платформу, другой процессор, несколько разных API.Старая платформа все еще нуждается в поддержке для исправлений ошибок и некоторых незначительных новых функций, что означает, что иногда будут появляться новые коды и исправления ошибок, которые необходимо объединить из новой версии в старую версию.

Теперь я вижуЭто можно сделать двумя способами:

1) Просто создайте ветку "legacy" для старой платформы, сделайте мой перенос на master и объедините то, что мне нужно для слияния с master на legacy

2) Проверьте существующий код, перенесите его на новую платформу и создайте из этого новое хранилище.Это означало бы, что мне иногда нужно объединить код прихода между этими двумя репозиториями, но у меня есть новое и свежее репо без 10-летней истории и более 50 заброшенных веток в нем.

Это второй способ выполнимый, т. е. возможно ли слияние (или вишнёк) между разными репо с общими предками?

Если да, то какой путь вы бы порекомендовали и почему?

Любые мысли высоко ценятся!

Редактировать: Еще одна причина для варианта 2) состоит в том, что было бы прощеделать, потому что мне нужно использовать новую IDE для новой платформы, т.е. мне нужно создать новый проект и скопировать код из старого проекта в новый проект.Затем я должен был бы как-то объяснить git, что этот проект, который я создал, является новым мастером, не вытащив его из репо.

Answer 1

Вы можете сохранить свой новый репозиторий github компактным и сфокусированным, не теряя историю, потому что вы можете извлекать / проталкивать произвольные истории где угодно, осиротить свою новую историю, и если вы обнаружите, что вам нужно что-то из старого, извлеките его оттуда и просмотрите / cherrypick/ все, что душе угодно.Извлечение кода утилиты из репозитория частных утилит - удобный трюк.

Answer 2

Я нахожусь в такой же ситуации: 20-летний репозиторий C, который должен работать на 25-летней 8-битной платформе и на очень свежем чипе ARM.Старый C-код содержит встроенную сборку, поэтому мне пришлось все это учитывать.Затем я написал программу переписывания clang, в которой реализованы некоторые современные функции C, и переработал их в терминах, понятных старому C-компилятору.Например, встроенные функции были расширены на месте на основе всегда встроенного атрибута, тогда как старый код ранее использовал для этого макросы (тьфу).Он также выпустил некоторые необходимые встроенные сборки, которые работают вокруг ошибок в старом компиляторе.Итак, я бы посоветовал вам сделать это только после того, как вы познакомитесь с основанным на clang переписыванием исходного кода на источник: в противном случае очень трудно написать читаемый код, который не вызывает миллион предупреждений и стилистических советов на современных компиляторах.Я, вероятно, напишу бэкэнд IR-to-C, поскольку он позаботится о большинстве пропущенных оптимизаций, с которыми оригинальный компилятор не смог бы справиться.