Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Ramkumar Ramachandra writes: >> The first patch implements Jakub's suggestion. Arguably, it's slightly >> complicated- it took me more than a few minutes to do the math with >> `nr` and `nr_i`. >> >> The second patch clarifies the meaning of the `-<n>` option. We should >> also probably force the mutual exclusivity of `-<n>` and <revision >> range> to avoid confusion. >> >> Additionally, thanks to Thomas for drilling into me the fundamental >> difference between -<n> and a revision range (on IRC). >> >> Ramkumar Ramachandra (2): >> git-format-patch: Print a diagnostic message when ignoring commits >> log: Improve description of '-<n>' option in documentation >> >> Documentation/git-format-patch.txt | 2 +- >> Documentation/git-log.txt | 2 +- >> builtin/log.c | 42 ++++++++++++++++++++++++++--------- >> 3 files changed, 33 insertions(+), 13 deletions(-) > > Do you see value in this patch or is it just unnecessary baggage? I am not very impressed by the counting. It probably makes more sense to count only what we are actually going to process and emit, i.e. always use no-merges (do we even support format-patch on a merge?). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html