Почему "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 10

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Эд? Совершаются ли коммиты в обоих направлениях, или они создаются только в одном РЕПО?