The -<n>
option of git format-patch
is a bit tricky, as this thread illustrates, from git contributor (for gitweb) and SO user Jakub Narębski:
It looks like there is a conceptual bug in how git-format-patch works, namely that '-<n>
' is passed to rev-list
/ log
generating machinery, and it limits number of commits to consider;
if some of those commits are merge commits, which cannot be represented as patches, the number of patches it generates is less than specified <n>
(as you can see in
the example I have provided, where <n>
== 3, and git-format-patch generated 2 patches, not 3).
In extreme case (like 'pu
') it can generate no patch.
(pu
being here the public branch of the git-scm repo.)
In the OP's case, as he points out in the comment, it could mean 19 commits that are merge patches.
Jakub goes on proposing the following solution:
Update git-format-patch
documentation to say 'commits' instead of 'patches',
and perhaps also be loud about commits we are skipping, so that my example would look e.g. like this:
$ git format-patch -3
0001-gitweb-Prepare-for-splitting-gitweb.txt
0002-gitweb-Create-Gitweb-Git-module.txt
Skipping merge commit: Merge branch 'maint'
, to which Ramkumar Ramachandra proposes last August (2010) to write a patch.
You can see that patch simmering in this September 2010 what's cooking in git.git
[New Topics]
rr/format-patch-count-without-merges
(2010-08-28) 2 commits
- format-patch
: Don't go over merge commits
- t4014-format-patch
: Call test_tick before committing
and is still in the latest what's cooking (Sept. 27th) in the [Cooking]
section, with the following annotation:
Comments from potential users?