У меня есть два несвязанных (не разделяющих каких-либо предков) в репозиториях Git, один - суперрепозиторий, который состоит из нескольких меньших проектов (Позволяет называть его репозиторием A). Другой - это временный локальный репозиторий Git для меньшего проекта (позволяет вызывать его репозиторий B). Графически это будет выглядеть как
A0-B0-C0-D0-E0-F0-G0-HEAD (repo A)
A0-B0-C0-D0-E0-F0-G0-HEAD (remote/master bare repo pulled & pushed from repo A)
A1-B1-C1-D1-E1-HEAD (repo B)
В идеале, мне бы очень хотелось объединить репо B в репо A с одной исторической шкалой. Таким образом, казалось бы, что я первоначально начал проект в репо А. Графически это был бы идеальный конечный результат
A0-A1-B1-B0-D1-C0-D0-E0-F0-G0-E1-H(from repo B)-HEAD (new repo A)
A0-A1-B1-B0-D1-C0-D0-E0-F0-G0-E1-H(from repo B)-HEAD (remote/master bare repo pulled & pushed from repo A)
Я делал некоторое чтение с подмодулями и поддеревом (Pro Git - довольно хорошая книга, кстати), но оба они, похоже, решают проблему сохранения двух отдельных ветвей с дополнительным модулем, способным вытащить изменения из вверх по течению и поддереву немного меньше головной боли. Оба решения требуют дополнительных и специализированных команд Git для обработки проверок и синхронизации между веткой master и sub tree/module. Оба решения также приводят к нескольким временным графикам (с поддеревом вы даже получаете 3 отдельных временных графика при использовании --squash).
Ближайшее решение из SO, похоже, говорит о трансплантате", но так ли это? Цель состоит в том, чтобы иметь единственный унифицированный репозиторий, в котором я могу вытащить/нажать check-ins, так что больше нет репо B, а просто репо A в конце.