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

[Michael J Gruber <git@drmicha.warpmail.net>]

Ævar Arnfjörð Bjarmason venit, vidit, dixit 07.03.2011 20:17:
> 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):

I don't think it's your design ;)

> 
>     $ 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

And that's exactly what it does - built in "tac", so to say.

> --walk-reflogs.
> 
> Shouldn't --reverse be applied *before* --max-count?

We could be clearer about the order in which these options are applied,
for example by listing the option blocks in that order and pointing out
--reverse in particular, see the upcoming little (squashable series).

Cheers,
Michael