У меня есть подпапка репо, которую я пытаюсь разделить на поддерево. Для начала я следовал этой процедуре ({ ссылка }), чтобы создать ветку, содержащую только коммиты, связанные с подпапкой (включая переименования). Я подтвердил, что журнал фиксации ветки выглядит так, как ожидалось.
Далее я создаю новое репо для этого подпроекта:
git init --bare \\nas\git\FPF.git
git push ssh://myserver.com/~/FPF.git branch-fpf:master
Затем я удаляю подпапку из родительского репо & re -добавить его как поддерево:
git rm -r htdocs/wp-content/plugins/fpf
git add -A
git commit -am "Removing folder to re-add as subtree"
git remote add fpf ssh://myserver.com/~/FPF.git
git subtree add --prefix=htdocs/wp-content/plugins/fpf fpf master --squash
Теперь, для быстрой проверки работоспособности, я возьму копию удаленного репозитория поддерева (конечно, в другой папке):
git clone ssh://myserver.com/~/FPF.git
И:
git subtree push --prefix=htdocs/wp-content/plugins/fpf fpf master
Поскольку я не совершал никаких изменений между добавлением поддерева и добавлением, я ожидаю, что в pu sh не будет ничего нового. Но, как оказалось, если я клонирую FPF. git еще раз, я обнаружил, что теперь у него есть ТОНА дополнительных коммитов - FPF вырос во много раз, с журналом коммитов, который теперь отражает множество коммитов, которые применяются только к файлам. вне поддерева.
Почему git поддерево pu sh будет выдавать коммиты, которые не применяются к поддереву?
Редактировать 1 : Дополнительные коммиты - это все коммиты из основного (родительского) репо, начиная с первого коммита FPF и возвращаясь к началу времени. Другими словами: если я сравниваю журналы репо поддерева FPF до и после выполнения git поддерева pu sh, они будут идентичны, пока я не доберусь до конца журнала клона «pre-pu sh» , Оттуда журнал клона «post-pu sh» продолжается вплоть до первого коммита родительского проекта. Git поддеревье pu sh эффективно добавило полную предысторию родителей.
Edit 2: Я решил отказаться от git -поддерева. Я обнаружил https://github.com/ingydotnet/git-subrepo, который не только работает должным образом, но и устраняет ряд недостатков поддерева (особенно ОЧЕНЬ медленные толчки). Оставляя этот вопрос здесь, на случай, если кто-то еще придет с ответом или борется с тем же, но для простоты, вот полный набор команд от начала до конца sh, которые показывают проблему. Отличие от вышеизложенного: это не начинается с ответвления, созданного путем объединения нескольких ответвлений-фильтров; он просто выполняет простейший случай разделения одного поддерева:
cd MainProjectRepo
git subtree split --prefix=htdocs/wp-content/plugins/fpf --branch=branch-new
git init --bare \\nas\git\FPF.git
git remote add fpf ssh://myserver.com/~/FPF.git
git push fpf branch-new:master
git rm -r htdocs/wp-content/plugins/fpf
git add -A
git commit -am "Removing folder to re-add as subtree"
git subtree add --prefix=htdocs/wp-content/plugins/fpf fpf master --squash
git clone ssh://myserver.com/~/FPF.git /tmp/fpf1
git subtree push --prefix=htdocs/wp-content/plugins/fpf fpf master
git clone ssh://myserver.com/~/FPF.git /tmp/fpf2
Как описано выше, fpf2 заканчивается всей историей коммитов из репо-источника.