--max-count useless with git-rev-list's --reverse

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On git.git, this works as expected, gives me the first 3 commits:

   $ git rev-list --reverse origin/master | head -n 3
    e83c5163316f89bfbde7d9ab23ca2e25604af290
    8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
    e497ea2a9b6c378f01d092c210af20cbee762475

Why is this so useless about ignoring the --reverse option, is this my
design (these are the 3 *latest* commits):

    $ git rev-list --reverse origin/master --max-count=3
    08fd8710e277eed73a21c6c5483c57bfeb14e8a7
    6d74e5c9dbe71e2eb63c6e8862ec979e9a5f068b
    07873dc5dd67398324278ff0d7627bb1a863ba89
    $ git rev-list origin/master --max-count=3
    07873dc5dd67398324278ff0d7627bb1a863ba89
    6d74e5c9dbe71e2eb63c6e8862ec979e9a5f068b
    08fd8710e277eed73a21c6c5483c57bfeb14e8a7

>From the manpage:

   --reverse
       Output the commits in reverse order. Cannot be combined with
--walk-reflogs.

Shouldn't --reverse be applied *before* --max-count?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]