Re: [PATCH v4 1/2] revision.c: implement --reverse=before for walks

[Junio C Hamano <gitster@pobox.com>]

Mirko Faina <mroik@delayed.space> writes:

> In a revision walk `--reverse` can only be applied after any commit
> limiting option. This makes getting a limited amount of commits from the
> tail impossible. E.g.
>
>     git log --reverse --max-count=3

Can we rephrase "from the tail" somehow to reduce ambiguity?

Normally we generate a list of commits from newer to older, and you
are saying that it is not possible to take the oldest three commits
and show them from older to newer (i.e., in reverse).  But that, to
some readers, is showing commits from the beginning end, not from
the tail end.

Perhaps "... limited number of oldest commits impossible"?

> Teach `get_revision()` to accpet an argument `(after|before)` from the
> CLI, and apply the reversal before or after the commit limiting options
> based on this argument.

I think "after" and "before" comes from "Do other things (including
count limiting) and then apply reverse after all that" and would be
very much understandable to those who know how the machinery works,
but should mere mortals need to know the machinery only to use "git
log"?

To put it another way, do you tnink experienced Git users who
haven't seen the actual implementation of revision traversal can
immediately answer this question:

    Now we have --reverse=after and --reverse=before to let you take
    a limited history from both ends when used with --max-count.
    Which between after and before do you think corresponds to the
    traditional --reverse that allowed you to only see the newest
    part of the history?

I doubt that the population to answer correctly would not exceed a
half by large margin (if it is 50% then it means nobody understood
the difference correctly and they just flipped a coin).

I wonder --reverse=oldest and --reverse=newest is easier to teach
and explain?  I dunno.