Почему "git subtree push" всегда перечисляет сотни коммитов?
Я использую поддерево git для совместного использования вложенной папки моего исходного кода между проектами. Это работает нормально, но каждый раз, когда я выполняю push поддерева git, терминал показывает постоянно растущий список коммитов:
git subtree push --prefix=public/js/engine engine-remote master --squash
git push using: engine-remote master
-n 1/ 1193 (0)
-n 2/ 1193 (1)
-n 3/ 1193 (2)
...
-n 1193/ 1193 (1152)
Counting objects: 176, done.
...
Почему это и могу ли я настроить что-то по-другому, чтобы предотвратить это? Я понимаю, что он должен проверить фиксации на родительском проекте, но я ожидал бы, что это будет только до точки последнего успешного вытягивания из поддерева.
1 ответ:
Ответ 0
Я не использую git-поддерево в своем ежедневном рабочем процессе, поэтому мне пришлось немного изучить это, но вот вам:
git subtree push
делаетgit subtree split
, за которым следуетgit push
. Команда, которая показывает этот список коммитов, на самом делеgit subtree split
. Еслиsplit
не находит commit, помеченный строкой aprropriate "git-subtree-dir:" в сообщении commit, то он проходит через всю историю проекта и создает новую историю, обрезанную до одного dir - в вашем случае это должно быть именно так.Как избежать это?
После успешного выполнения
git subtree push
, вы можете сделатьgit subtree split --rejoin
[1]. Это создаст пустой коммит слияния, который соединит историю поддерева с историей вашего проекта; будущие вызовыgit subtree
будут использовать сообщение от этого коммита слияния при разбиении истории поддерева [2]. Та же самая информация должна быть помещена в коммит слияния послеgit subtree pull
, но часто этого не происходит (иногда это так)[3]; вы можете сделатьgit subtree split
послеgit subtree pull
, но результирующий граф выглядит уродливо. См. [3], пожалуйста.Ответ 1
Это действительно плохо? Приятно, что это распечатано. После каждой строки выводится каретка-возврат, поэтому я получаю красивую "анимацию", которая идет от 0 до n (в одной строке - не вывод, который вы вставили в свой вопрос). Может быть, ваш терминал не распознает возврат каретки (это может быть проблемой в Windows или OS X, я думаю)? Какую ОС вы используете?
Ответ 2
Вы можете скрыть это с помощью
-q|--quiet
, Если вы не можете использоватьsplit --rejoin
, и этот вывод действительно беспокоит ты.Ссылки и мои комментарии
[19]}[1] но будьте бдительны! man page говорит:Так что используйтеЕсли вы делаете все свои слияния с ' - squash ', Не используйте' - rejoin', когда вы разделяетесь, потому что вы не хотите, чтобы история подпроекта была частью вашего проекта в любом случае.
--rejoin
, Если это уместно в вашей конкретной ситуации.[2] Возможно, это могло бы быть достигнуто лучше, но
git-subtree
не может хранить это в самом объекте commit, потому что это не родная особенность git (пока?). Это скрипт bash, который вы можете найти в каталоге contrib/: https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh Это, вероятно, причина, почему документация для этой функции скудна (Эй, но man page великолепен).[3] Я немного экспериментировал и иногда видел, как появляется правильный коммит слияния-как - то это связано с ситуациями, когда
git subtree pull
приводило к конфликту. Это, вероятно, указывает на ошибку в git-subtree.sh; дайте мне больше информации, так что я могу исследовать его дальше (и, надеюсь, исправить). Я просмотрел историю этого файла и не увидел никаких соответствующих исправлений...Какую версию git вы используете? (мой - 1.9.3). Каков ваш рабочий процесс с этим общим каталогом? Это был
git subtree add
Эд? Совершаются ли коммиты в обоих направлениях, или они создаются только в одном РЕПО?