Опция -<n> в git format-patch немного хитрая, так как этот поток иллюстрирует от git contributor (для gitweb) и пользователя SO Якуб Наребски :
Похоже, есть концептуальная ошибка в работе git-format-patch, а именно то, что -<n> передается на rev-list / log генерирующее оборудование, и ограничивает число обязуется рассмотреть ;
если некоторые из этих коммитов являются коммитами слияния, которые не могут быть представлены как патчи, количество генерируемых патчей меньше указанного <n> (как вы можете видеть в
Пример, который я привел, где <n> == 3, а git-format-patch сгенерировал 2 патча, а не 3).
В крайнем случае (например, pu) он не может генерировать патч.
(pu здесь находится публичная ветка репозитория git-scm .)
В случае ОП, как он указывает в комментарии, это может означать 19 коммитов, которые являются патчами слияния.
Якуб продолжает предлагать следующее решение:
Обновление git-format-patch документации, в которой говорится "коммиты" вместо "патчей",
и, возможно, также быть громким о коммитах, которые мы пропускаем, чтобы мой пример выглядел, например, как это:
$ git format-patch -3
0001-gitweb-Prepare-for-splitting-gitweb.txt
0002-gitweb-Create-Gitweb-Git-module.txt
Skipping merge commit: Merge branch 'maint'
, к которому Рамкумар Рамачандра предлагает в августе (2010 г.) написать патч .
Вы можете видеть, что патч кипит в этом сентябре 2010 года, что готовится в git.git
[Новые темы]
rr/format-patch-count-without-merges (2010-08-28) 2 коммита
- format-patch: не переходить через слияния
- t4014-format-patch: вызовите test_tick перед совершением
и все еще в последней версии что готовит (27 сентября) в разделе [Cooking] со следующей аннотацией:
Комментарии от потенциальных пользователей?