Почему '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 -subtree в своем ежедневном рабочем процессе, поэтому мне пришлось немного исследовать это, но здесь вы идете:

git subtree push выполняет git subtree split, за которым следует git push. Команда, показывающая этот список коммитов, на самом деле git subtree split. Если split не обнаружит фиксацию, помеченную подходящей линией "git -subtree-dir:" в сообщении фиксации, тогда она проходит всю историю проекта и создает новую историю, обрезанную до одного каталога - в вашем случае это должно быть делая именно это.

Как этого избежать?

После успешного git subtree push вы можете сделать git subtree split --rejoin [1]. Это создаст пустую транзакцию слияния, которая объединит историю поддерева с историей вашего проекта; будущие вызовы git subtree будут использовать сообщение из этого объединения при расщеплении истории subdir [2]. Та же информация должна быть помещена в фиксацию слияния после git subtree pull, но часто это не так (иногда это) [3]; вы можете сделать git subtree split после git subtree pull, но полученный граф выглядит уродливым. См. [3], пожалуйста.

Ответ 1

Неужели это плохо? Приятно напечатать это. После того, как каждая строка возвращает карету, я получаю приятную "анимацию", которая идет от 0 до n (в одной строке - не выводится, которую вы вставили в свой вопрос). Может быть, ваш терминал не распознает возврат каретки (возможно, это проблема в Windows или OS X, я думаю)? Какую ОС вы используете?

Ответ 2

Вы можете скрыть это с помощью -q|--quiet, если вы не можете использовать split --rejoin, и этот вывод действительно вас беспокоит.

Ссылки и комментарии

[1], но будьте в курсе! man говорит:

Если вы делаете все свои слияния с "--squash" , не используйте "-rejoin", когда вы разделяете, потому что вы не хотите, чтобы история подпроектов была частью вашего проект в любом случае.

Поэтому используйте --rejoin, если это соответствует вашей конкретной ситуации.

[2] Возможно, это может быть достигнуто лучше, но git-subtree не может хранить это в самом объекте commit, потому что это не родная функция git (еще?). Это bash script, который вы можете найти в каталоге contrib/: https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh Вероятно, причина в том, почему документация для этой функции малочисленна (эй, но справочная страница велика).

[3] Я немного экспериментировал и иногда видел правильное коммандное слияние - как-то это кажется связанным с ситуациями, когда git subtree pull привело к конфликту. Вероятно, это указывает на ошибку в git -subtree.sh; дайте мне больше информации, поэтому я могу исследовать ее дальше (и, надеюсь, исправить ее). Я просмотрел историю этого файла и не видел соответствующих исправлений...

Какую версию git вы используете? (шахта - 1,9,3). Каков ваш рабочий процесс с этим общим каталогом? Было ли это git subtree add ed? Выполняет ли поток оба пути или они созданы только в одном репо?