git: запушить свой проект в подкаталог удаленного репозитория

man git submodules.

1 проект - 1 репозиторий. Но если хочется их собрать все вместе, то есть submodules.

Если submodule выберешь, то твой проект придется хранить в отдельном репе и через submidule подключать.

Есть вуду магия под названием subtree merge

Чет почитал про все это. И напала на меня депрессия.

А нет ли царского пути в этой «геометрии»?

Про порочность этой идеи и правильный submodule уже написали, а вообще это делается просто - делаешь коммит в служебном проекте который перемещает всё в нужную поддиректорию (по вкусу можно вместо этого сделать filter-branch чтобы выглядело так как будно он всегда был в этой поддиректории), потом добавляешь этот репозиторий как remote в основном репозитории и делаешь merge --allow-unrelated-histories.

Не понимаю страданий, если честно..

В склонированном локально основном репе делаешь git remote add foo урл твоего репа

Далее https://til.hashrocket.com/posts/babf63d378-use-git-subtree-to-merge-repositories-with-history

О, да, unrelated-histories, конечно, круче. Особенно, историю комитетов сохранит..

Страдание в том, что ничего не понятно. Что произойдет в результате этого действия? Как история моих коммитов будет соседствовать с историей исходной репы? Много вопросов.

Если делать submodules, то где будет хранится история?

Сохранит, причём в первозданном виде.

submodule - это когда репозиторий со вспомогательным проектом остаётся отдельным репозиторием. А в основном появляется каталог который на него ссылается, на определённый коммит. Соответственно всё можно разрабатывать независимо, коммиты во вспомогательный проект пойдут в его репозиторий, а в основном будет видно только переключения submodule на новый коммит. Тогда и только тогда когда оно нужно, никаких лишних мержей и никакого смешения истории.

В сабмодулях своя история, не связанная с основным репо.

Если тебе один раз слить и работать потом а основном, сделай сабтри мерж и забудь об этом.

В сабмодулях своя история, не связанная с основным репо

А где она физически будет хранится?

Мне бы хотелось чтобы история моих коммитов стала историей основной репы. Пусть даже в виде последовательности коммитов с одинаковым таймстемпом на момент мерджа.

сделай сабтри мерж и забудь об этом.

как в этом случае будет выглядеть история коммитов основного репозитория?

Физически - в том репе, который ты подключаешь, как сабмодуль.

Это как «мягкие ссылки» в фс

Выполни у себя на тачке эти действия, и увидишь. Рушить ничего не придется, чтобы увидеть результат. Гит лог наберёшь и увидишь всё

Тогда мерж. История будет выглядеть так:

o merge commit
|\
| o история
| o влитого
| o проекта
| o ...
o история
o основного
o проекта
o ...

Самый быстрый способ - запилить скрипт, который по шагам воспроизведет историю твоего репозитория в другом. На баше пишеться за 2-3 часа.

Всё это элементарно возможно. Гугли import existing git into subdirectory. В своё время сводил так дюжину сервисов в моно-репо с сохранением истории.

Например так: https://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another

Отвечу в назидание потомкам:

добавить стороннюю репу в текущую: git subtree add -P subproject ../subproject master

Проблемы: 1. в слаке по умолчанию не собирается инструмент git-subtree. Нужно править слакбилд, причем как в 14.2 так и в current

2. Нельзя вставлять в пустой репозиторий. Там должен быть хотя бы один commit. Скрипт subtree работает c HEAD.

Как итог, добавляется branch c подпроектом, который потом мерджится с master-ом.

главное чтобы потом найденное решение не мешало делать например git cherry

Как я понял делается это через создание бранча, добавление истории к этому бранчу и потом мердж обратно в мастер. То есть этот subtree всего лишь автоматизация того, что я описал. А так можно руками все сделать.

Теоретически, наверное - да: в отдельную ветку положить все, только относящееся к subtree и потом можно просто мерж сделать с целевой веткой.

подумалось только это в принципе невозможно

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

я хз ( не пробовал), но вроде как нет.