> 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
> 
> Some would expect this to give back the first 3 commits of the project.
> Instead it returns the last 3 but in reversed order.
> 
> 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. If no argument is provided default to the
> current behaviour, applying `--reverse` after the commit limiting
> options.

> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
>   Documentation/rev-list-options.adoc |  6 ++--
>   revision.c                          | 42 ++++++++++++++++++++++---
>   revision.h                          |  7 ++++-
>   t/t4202-log.sh                      | 49 +++++++++++++++++++++++++++++
>   4 files changed, 97 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index 2d195a1474..eed1813a92 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -914,10 +914,12 @@ With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
>   avoid showing the commits from two parallel development track mixed
>   together.
>   
> -`--reverse`::
> +`--reverse[=(after|before)]`::
>   	Output the commits chosen to be shown (see 'Commit Limiting'
>   	section above) in reverse order. Cannot be combined with
> -	`--walk-reflogs`.
> +	`--walk-reflogs`. `when` can either be `after` or `before`, if
> +	omitted it defaults to `after`. If `before` is chosen,
> +	`--reverse` will be applied before any commit limiting options.
>   endif::git-shortlog[]
>   
>   ifndef::git-shortlog[]
> diff --git a/revision.c b/revision.c
> index 599b3a66c3..8338ea7448 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2685,8 +2685,26 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>   		else
>   			git_log_output_encoding = xstrdup("");
>   		return argcount;
> -	} else if (!strcmp(arg, "--reverse")) {
> -		revs->reverse ^= 1;
> +	} else if (starts_with(arg, "--reverse")) {
> +		if (!skip_prefix(arg, "--reverse=", &optarg)) {
> +			if (argc < 2) {
> +				revs->reverse = 1;
> +				return 1;
> +			} else {
> +				optarg = argv[1];
> +			}
> +		}
> +
> +		if (!strcmp(optarg, "after")) {
> +			revs->reverse = 1;
> +		} else if (!strcmp(optarg, "before")) {
> +			revs->reverse = 2;
> +		} else {
> +			revs->reverse = 1;
> +			return 1;
> +		}
> +
> +		return optarg == argv[1] ? 2 : 1;
>   	} else if (!strcmp(arg, "--children")) {
>   		revs->children.name = "children";
>   		revs->limited = 1;
> @@ -4525,19 +4543,35 @@ struct commit *get_revision(struct rev_info *revs)
>   {
>   	struct commit *c;
>   	struct commit_list *reversed;
> +	int max_count = revs->max_count;
> +
> +	if (revs->reverse && !revs->reverse_output_stage) {
> +		if (revs->reverse == 3) {
> +			BUG("allowed values for reverse are 0, 1 and 2");
> +			revs->reverse = 1;
> +		}
> +
> +		if (revs->reverse == 2)
> +			revs->max_count = -1;

>   
> -	if (revs->reverse) {
>   		reversed = NULL;
>   		while ((c = get_revision_internal(revs)))
>   			commit_list_insert(c, &reversed);
>   		commit_list_free(revs->commits);
>   		revs->commits = reversed;
> -		revs->reverse = 0;
>   		revs->reverse_output_stage = 1;
> +
> +		if (revs->reverse == 2)
> +			revs->max_count = max_count;
>   	}
>   
>   	if (revs->reverse_output_stage) {
> +		if (revs->reverse == 2 && revs->max_count == 0)
> +			return NULL;
> +
>   		c = pop_commit(&revs->commits);
> +		if (revs->reverse == 2)
> +			revs->max_count--;
>   		if (revs->track_linear)
>   			revs->linear = !!(c && c->object.flags & TRACK_LINEAR);
>   		return c;
> diff --git a/revision.h b/revision.h
> index 584f1338b5..5b23343f17 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -196,7 +196,12 @@ struct rev_info {
>   			rewrite_parents:1,
>   			print_parents:1,
>   			show_decorations:1,
> -			reverse:1,
> +			/*
> +			 * 0 no reverse
> +			 * 1 after
> +			 * 2 before
> +			 */
> +			reverse:2,
>   			reverse_output_stage:1,
>   			cherry_pick:1,
>   			cherry_mark:1,
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 05cee9e41b..21e9a61994 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -1882,6 +1882,55 @@ test_expect_success 'log --graph with --name-status' '
>   	test_cmp_graph --name-status tangle..reach
>   '
>   
> +cat >expect <<-\EOF
> +c3f451c Merge tag 'reach'
> +046b221 to remove
> +EOF
> +
> +test_expect_success 'log --reverse --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse after --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse after --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse=after --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse=after --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +cat >expect <<-\EOF
> +3a2fdcb initial
> +f7dab8e second
> +EOF
> +
> +test_expect_success 'log --reverse before --oneline --max-count=2' '
> +	test_when_finished rm actual &&
> +	git log --reverse before --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse=before --oneline --max-count=2' '
> +	test_when_finished rm actual &&
> +	git log --reverse=before --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
>   cat >expect <<-\EOF
>   * reach
>   |
> 
> base-commit: e8955061076952cc5eab0300424fc48b601fe12d

> On 4/19/26 00:47, Mirko Faina wrote:
> > 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
> > 
> > Some would expect this to give back the first 3 commits of the project.
> > Instead it returns the last 3 but in reversed order.
> > 
> > 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. If no argument is provided default to the
> > current behaviour, applying `--reverse` after the commit limiting
> > options.
> 
> Reasoning looks good to me.
> 
> Nit: I think we could gather more feedback on the naming. If I were a user
> unfamiliar with how Git works, the most natural and intuitive operation for
> me would be: "Show me the three *oldest* commits" (to be more precise,
> *oldest* in the sense of topological order, rather than the commit date or
> author date order. It’s really annoying. ), rather than "reverse the entire
> list and then select the three most recent ones". I think the confusion
> arises because users do not (and should not) know that '--max-count' only
> returns the most recent commits; consequently, they might wonder: "Well, the
> 'after' and 'before' parameters do make a difference, but why?". I believe
> it is best not to lead users to this point.

> > @@ -4525,19 +4543,35 @@ struct commit *get_revision(struct rev_info *revs)
> >   {
> >   	struct commit *c;
> >   	struct commit_list *reversed;
> > +	int max_count = revs->max_count;
> > +
> > +	if (revs->reverse && !revs->reverse_output_stage) {
> > +		if (revs->reverse == 3) {
> > +			BUG("allowed values for reverse are 0, 1 and 2");
> > +			revs->reverse = 1;
> > +		}
> > +
> > +		if (revs->reverse == 2)
> > +			revs->max_count = -1;
> 
> I think the space complexity here could be reduced a little. After all,
> since we’re only retrieving a few commits, there’s no need to load the
> entire reversed commit history into memory.
> 
> Perhaps we could maintain a window (or perhaps max heap) of finite length?

> > I think the space complexity here could be reduced a little. After all,
> > since we’re only retrieving a few commits, there’s no need to load the
> > entire reversed commit history into memory.
> > 
> > Perhaps we could maintain a window (or perhaps max heap) of finite length?
> 
> Unfortunately since the underlying data structure is a linked list we
> have to traverse the whole tree to get the first one from the tail. The
> way get_revision() loads the next commit is through process_parents().
> Even if we were able to start from the tail we wouldn't have any
> reference to the children.
> 
> I suspect reducing space complexity would require to change a lot of
> inner workings of git to make the history traversable both ways.

> Le 18 avr. 2026 à 12:57, Mirko Faina <mroik@delayed.space> a écrit :
> 
> 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
> 
> Some would expect this to give back the first 3 commits of the project.
> Instead it returns the last 3 but in reversed order.
> 
> 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. If no argument is provided default to the
> current behaviour, applying `--reverse` after the commit limiting
> options.
> 
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
> Documentation/rev-list-options.adoc |  6 ++--
> revision.c                          | 42 ++++++++++++++++++++++---
> revision.h                          |  7 ++++-
> t/t4202-log.sh                      | 49 +++++++++++++++++++++++++++++
> 4 files changed, 97 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index 2d195a1474..eed1813a92 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -914,10 +914,12 @@ With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
> avoid showing the commits from two parallel development track mixed
> together.
> 
> -`--reverse`::
> +`--reverse[=(after|before)]`::
>    Output the commits chosen to be shown (see 'Commit Limiting'
>    section above) in reverse order. Cannot be combined with
> -    `--walk-reflogs`.
> +    `--walk-reflogs`. `when` can either be `after` or `before`, if

> +    omitted it defaults to `after`. If `before` is chosen,
> +    `--reverse` will be applied before any commit limiting options.
> endif::git-shortlog[]
> 
> ifndef::git-shortlog[]
> diff --git a/revision.c b/revision.c
> index 599b3a66c3..8338ea7448 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2685,8 +2685,26 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>        else
>            git_log_output_encoding = xstrdup("");
>        return argcount;
> -    } else if (!strcmp(arg, "--reverse")) {
> -        revs->reverse ^= 1;

> +    } else if (starts_with(arg, "--reverse")) {
> +        if (!skip_prefix(arg, "--reverse=", &optarg)) {
> +            if (argc < 2) {
> +                revs->reverse = 1;
> +                return 1;
> +            } else {
> +                optarg = argv[1];
> +            }
> +        }
> +
> +        if (!strcmp(optarg, "after")) {
> +            revs->reverse = 1;
> +        } else if (!strcmp(optarg, "before")) {
> +            revs->reverse = 2;
> +        } else {
> +            revs->reverse = 1;
> +            return 1;
> +        }
> +
> +        return optarg == argv[1] ? 2 : 1;

>    } else if (!strcmp(arg, "--children")) {
>        revs->children.name = "children";
>        revs->limited = 1;
> @@ -4525,19 +4543,35 @@ struct commit *get_revision(struct rev_info *revs)
> {
>    struct commit *c;
>    struct commit_list *reversed;
> +    int max_count = revs->max_count;
> +
> +    if (revs->reverse && !revs->reverse_output_stage) {
> +        if (revs->reverse == 3) {
> +            BUG("allowed values for reverse are 0, 1 and 2");
> +            revs->reverse = 1;
> +        }

> +
> +        if (revs->reverse == 2)
> +            revs->max_count = -1;
> 
> -    if (revs->reverse) {
>        reversed = NULL;
>        while ((c = get_revision_internal(revs)))
>            commit_list_insert(c, &reversed);
>        commit_list_free(revs->commits);
>        revs->commits = reversed;
> -        revs->reverse = 0;
>        revs->reverse_output_stage = 1;
> +
> +        if (revs->reverse == 2)
> +            revs->max_count = max_count;
>    }

> 
>    if (revs->reverse_output_stage) {
> +        if (revs->reverse == 2 && revs->max_count == 0)
> +            return NULL;
> +
>        c = pop_commit(&revs->commits);
> +        if (revs->reverse == 2)
> +            revs->max_count--;

>        if (revs->track_linear)
>            revs->linear = !!(c && c->object.flags & TRACK_LINEAR);
>        return c;
> diff --git a/revision.h b/revision.h
> index 584f1338b5..5b23343f17 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -196,7 +196,12 @@ struct rev_info {
>            rewrite_parents:1,
>            print_parents:1,
>            show_decorations:1,
> -            reverse:1,
> +            /*
> +             * 0 no reverse
> +             * 1 after
> +             * 2 before
> +             */
> +            reverse:2,
>            reverse_output_stage:1,
>            cherry_pick:1,
>            cherry_mark:1,
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 05cee9e41b..21e9a61994 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -1882,6 +1882,55 @@ test_expect_success 'log --graph with --name-status' '
>    test_cmp_graph --name-status tangle..reach
> '
> 
> +cat >expect <<-\EOF
> +c3f451c Merge tag 'reach'
> +046b221 to remove
> +EOF
> +
> +test_expect_success 'log --reverse --oneline --max-count=2' '
> +    test_when_finished git reset --hard HEAD~1 &&
> +    touch to_remove &&
> +    git add to_remove &&
> +    git commit -m "to remove" &&
> +    git log --reverse --oneline --max-count=2 >actual &&
> +    test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse after --oneline --max-count=2' '
> +    test_when_finished git reset --hard HEAD~1 &&
> +    touch to_remove &&
> +    git add to_remove &&
> +    git commit -m "to remove" &&
> +    git log --reverse after --oneline --max-count=2 >actual &&
> +    test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse=after --oneline --max-count=2' '
> +    test_when_finished git reset --hard HEAD~1 &&
> +    touch to_remove &&
> +    git add to_remove &&
> +    git commit -m "to remove" &&
> +    git log --reverse=after --oneline --max-count=2 >actual &&
> +    test_cmp expect actual
> +'
> +
> +cat >expect <<-\EOF
> +3a2fdcb initial
> +f7dab8e second
> +EOF
> +
> +test_expect_success 'log --reverse before --oneline --max-count=2' '
> +    test_when_finished rm actual &&
> +    git log --reverse before --oneline --max-count=2 >actual &&
> +    test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse=before --oneline --max-count=2' '
> +    test_when_finished rm actual &&
> +    git log --reverse=before --oneline --max-count=2 >actual &&
> +    test_cmp expect actual
> +'
> +
> cat >expect <<-\EOF
> * reach
> |
> 
> base-commit: e8955061076952cc5eab0300424fc48b601fe12d
> --
> 2.54.0.rc2.9.ge895506107
> 
> 

> > -`--reverse`::
> > +`--reverse[=(after|before)]`::
> >    Output the commits chosen to be shown (see 'Commit Limiting'
> >    section above) in reverse order. Cannot be combined with
> > -    `--walk-reflogs`.
> > +    `--walk-reflogs`. `when` can either be `after` or `before`, if
> 
> “When” is not mentioned prior to here, so it’s explanation leaves the reader wondering what it refers to.

> The original handles multiple reverse options inverting each other…
> 
> > +    } else if (starts_with(arg, "--reverse")) {
> > +        if (!skip_prefix(arg, "--reverse=", &optarg)) {
> > +            if (argc < 2) {
> > +                revs->reverse = 1;
> > +                return 1;
> > +            } else {
> > +                optarg = argv[1];
> > +            }
> > +        }
> > +
> > +        if (!strcmp(optarg, "after")) {
> > +            revs->reverse = 1;
> > +        } else if (!strcmp(optarg, "before")) {
> > +            revs->reverse = 2;
> > +        } else {
> > +            revs->reverse = 1;
> > +            return 1;
> > +        }
> > +
> > +        return optarg == argv[1] ? 2 : 1;
> 
> …which I don’t see here.
> 
> I’m not familiar with this parsing code though so I can’t add much about the test other than to say it is a bit hard to follow :/

> >    } else if (!strcmp(arg, "--children")) {
> >        revs->children.name = "children";
> >        revs->limited = 1;
> > @@ -4525,19 +4543,35 @@ struct commit *get_revision(struct rev_info *revs)
> > {
> >    struct commit *c;
> >    struct commit_list *reversed;
> > +    int max_count = revs->max_count;
> > +
> > +    if (revs->reverse && !revs->reverse_output_stage) {
> > +        if (revs->reverse == 3) {
> > +            BUG("allowed values for reverse are 0, 1 and 2");
> > +            revs->reverse = 1;
> > +        }
> 
> Is this possible? I guess I can see from the expanded bit width that it’s a valid input, and there’s no protection stopping other callers accidentally adding this.

> > 
> >    if (revs->reverse_output_stage) {
> > +        if (revs->reverse == 2 && revs->max_count == 0)
> > +            return NULL;
> > +
> >        c = pop_commit(&revs->commits);
> > +        if (revs->reverse == 2)
> > +            revs->max_count--;
> 
> Hm. Why do we decrement here? Again, not an area I’m familiar with, but a bit surprising. 

>
> On Sun, Apr 19, 2026 at 08:06:24AM -0400, Ben Knoble wrote:
> > The original handles multiple reverse options inverting each other…
> >
> > > +    } else if (starts_with(arg, "--reverse")) {
> > > +        if (!skip_prefix(arg, "--reverse=", &optarg)) {
> > > +            if (argc < 2) {
> > > +                revs->reverse = 1;
> > > +                return 1;
> > > +            } else {
> > > +                optarg = argv[1];
> > > +            }
> > > +        }
> > > +
> > > +        if (!strcmp(optarg, "after")) {
> > > +            revs->reverse = 1;
> > > +        } else if (!strcmp(optarg, "before")) {
> > > +            revs->reverse = 2;
> > > +        } else {
> > > +            revs->reverse = 1;
> > > +            return 1;
> > > +        }
> > > +
> > > +        return optarg == argv[1] ? 2 : 1;
> >
> > …which I don’t see here.
> >
> > I’m not familiar with this parsing code though so I can’t add much about the test other than to say it is a bit hard to follow :/
>
> Given that it is no longer binary handling multiple reverse can't simply
> be inverting bits, it wouldn't make sense. This is done before the walk
> itself, so even from the POV of the user it wouldn't make much sense to
> reverse multiple times as the order of the applied options before this
> patch (commit limiting options then reverse) doesn't change.
>
> This doesn't break any tests so I assumed it was fine.

> > >    } else if (!strcmp(arg, "--children")) {
> > >        revs->children.name = "children";
> > >        revs->limited = 1;
> > > @@ -4525,19 +4543,35 @@ struct commit *get_revision(struct rev_info *revs)
> > > {
> > >    struct commit *c;
> > >    struct commit_list *reversed;
> > > +    int max_count = revs->max_count;
> > > +
> > > +    if (revs->reverse && !revs->reverse_output_stage) {
> > > +        if (revs->reverse == 3) {
> > > +            BUG("allowed values for reverse are 0, 1 and 2");
> > > +            revs->reverse = 1;
> > > +        }
> >
> > Is this possible? I guess I can see from the expanded bit width that it’s a valid input, and there’s no protection stopping other callers accidentally adding this.
>
> Current code should never generate a 3, but in case it happens I assume
> the user wants to use the original behaviour of reverse, so I set the
> value accordingly instead of stopping the program and notify that
> there's a bug.
>
> Should this be changed?

> > I haven’t looked, but it would be nice if we could use an enum instead. Unfortunately that would probably take up more space in the struct, and I suppose the bit-packing is done intentionally for performance.
>
> Could define new macros so that the readers don't have to mentally keep
> track of which value rapresents what. I didn't think that was
> necessary, should I change it?

> > >        c = pop_commit(&revs->commits);
> > > +        if (revs->reverse == 2)
> > > +            revs->max_count--;
> >
> > Hm. Why do we decrement here? Again, not an area I’m familiar with, but a bit surprising.
>
> get_revision() (in revision.c) handles the reverse option and updates
> the "struct git_graph". get_revision() then calls
> get_revision_internal(), which handles commit boundaries and max_count,
> here is where it gets decreased. Since max_count gets decreased
> everytime get_revision_internal() is called, if we were to leave
> max_count as is before the walk (in get_revision() at line 4558), the
> walk would stop before reaching the root commit. This is why the current
> --reverse option is applied only after commit limiting options. So
> instead we set max_count at -1 walking the whole history and storing it
> in 'reversed'. Now we're in "reverse_output_stage = 1", and in this
> state we never call get_revision_internal() again, instead we pop
> commits from 'reversed'. Because of this we have to handle max_count
> outside get_revision_internal(), so we decrement it in the snippet of
> code you referenced.
>
> A bit verbose but hopefully it'll get my point across.

> On Sun, Apr 19, 2026 at 2:11 PM Mirko Faina <mroik@delayed.space> wrote:
> >
> > On Sun, Apr 19, 2026 at 08:06:24AM -0400, Ben Knoble wrote:
> > > The original handles multiple reverse options inverting each other…
> > >
> > > > +    } else if (starts_with(arg, "--reverse")) {
> > > > +        if (!skip_prefix(arg, "--reverse=", &optarg)) {
> > > > +            if (argc < 2) {
> > > > +                revs->reverse = 1;
> > > > +                return 1;
> > > > +            } else {
> > > > +                optarg = argv[1];
> > > > +            }
> > > > +        }
> > > > +
> > > > +        if (!strcmp(optarg, "after")) {
> > > > +            revs->reverse = 1;
> > > > +        } else if (!strcmp(optarg, "before")) {
> > > > +            revs->reverse = 2;
> > > > +        } else {
> > > > +            revs->reverse = 1;
> > > > +            return 1;
> > > > +        }
> > > > +
> > > > +        return optarg == argv[1] ? 2 : 1;
> > >
> > > …which I don’t see here.
> > >
> > > I’m not familiar with this parsing code though so I can’t add much about the test other than to say it is a bit hard to follow :/
> >
> > Given that it is no longer binary handling multiple reverse can't simply
> > be inverting bits, it wouldn't make sense. This is done before the walk
> > itself, so even from the POV of the user it wouldn't make much sense to
> > reverse multiple times as the order of the applied options before this
> > patch (commit limiting options then reverse) doesn't change.
> >
> > This doesn't break any tests so I assumed it was fine.
> 
> I think I mean that
> 
>     git log --reverse --reverse
> 
> shows commits in the same order as "git log"; what should
> 
>     git log --reverse=after --reverse
> 
> do? Or what about preserving the behavior of the original "git log
> --reverse --reverse," which I don't think is done here?

> Granted, I don't see this ability documented, and I cannot tell how
> many may scream if we change this behavior, so it's a bit
> hypothetical. But there is an argument for backward compatibility as a
> default, which I think we'd need to justify changing. Perhaps in the
> proposed log message?
> 
> (The original seems nonsensical to type, but of course you can imagine
> alias.A=log --reverse <other-stuff>, and then sometimes you want to do
> "git A --reverse" to un-reverse the commits.)

> > > I haven’t looked, but it would be nice if we could use an enum instead. Unfortunately that would probably take up more space in the struct, and I suppose the bit-packing is done intentionally for performance.
> >
> > Could define new macros so that the readers don't have to mentally keep
> > track of which value rapresents what. I didn't think that was
> > necessary, should I change it?
> 
> Yeah, a few `#define`d constants would make things more readable to
> me, at least, since we can't use the enum without space concerns
> (unless there's a way to bit-pack the enum to only 2 bits?).

> > > >    if (revs->reverse_output_stage) {
> > > > +        if (revs->reverse == 2 && revs->max_count == 0)
> > > > +            return NULL;
> > > > +
> 
> PS: something I spotted on a second read. [Ignoring reverse=after
> mode] This hunk looks to me like a nice little optimization (return
> nothing if we know max_count says we yield no commits). Of course, I
> could see that being viable early in the function, right? When asking
> get_revision for commits, if max_count is 0, just return NULL.
> 
> For reverse=after mode, this condition is only true if the max_count
> was 0 in the previous conditional, also, since we use max_count=-1
> before iterating get_revision_internal. That means the original
> max_count isn't touched. At any rate, it _seems_ to me that the whole
> function could benefit from this optimization… but I wonder if it is
> _necessary_ for correctness of reverse=after in some way that I'm not
> seeing? Since the current version doesn't need the early bailout, why
> does reverse=after?

> > > >        c = pop_commit(&revs->commits);
> > > > +        if (revs->reverse == 2)
> > > > +            revs->max_count--;
> > >
> > > Hm. Why do we decrement here? Again, not an area I’m familiar with, but a bit surprising.
> >
> > get_revision() (in revision.c) handles the reverse option and updates
> > the "struct git_graph". get_revision() then calls
> > get_revision_internal(), which handles commit boundaries and max_count,
> > here is where it gets decreased. Since max_count gets decreased
> > everytime get_revision_internal() is called, if we were to leave
> > max_count as is before the walk (in get_revision() at line 4558), the
> > walk would stop before reaching the root commit. This is why the current
> > --reverse option is applied only after commit limiting options. So
> > instead we set max_count at -1 walking the whole history and storing it
> > in 'reversed'. Now we're in "reverse_output_stage = 1", and in this
> > state we never call get_revision_internal() again, instead we pop
> > commits from 'reversed'. Because of this we have to handle max_count
> > outside get_revision_internal(), so we decrement it in the snippet of
> > code you referenced.
> >
> > A bit verbose but hopefully it'll get my point across.
> 
> I don't 100% follow, but I'm out of my depth :)
> 
> I think I see that get_revision() effectively has 2 modes pertaining
> to reverse: reverse and reverse output stage (the former falls
> directly into the latter, though).
> 
> After some setup, the reverse mode calls get_revision_internal() as
> you said. That decrements max_count as a way of counting how many
> commits we've seen through the loop, so if we asked for 5 we'd only
> process 5 commits.
> 
> Then we fall into the output stage mode, which pops a commit [1].
> 
> With this patch, in reverse=after we disable max_count in the first
> (reverse) mode, as you said. Ok: we get the whole (filtered) history
> then, at which point we can now shrink. That makes sense.
> 
> Then in the reverse output stage mode, we pretend to have one less
> max_count. That's what I can't figure out. Is it because of the
> pop_commit()? I guess I'm not totally seeing how that interacted with
> the max_count in the original code: does the current code yield one
> extra commit in get_revision_internal() ?

> You wrote that "we never call get_revision_internal() again," but I
> don't see why that's true with this patch and not true before it.
> 
> I do agree that _somebody_ has to handle max_count after
> get_revision() returns with reverse=after. I'm just not sure what
> 
>     if (revs->reverse == 2)
>         revs->max_count--;
> 
> is doing.

> @@ -2685,8 +2685,26 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>  		else
>  			git_log_output_encoding = xstrdup("");
>  		return argcount;
> -	} else if (!strcmp(arg, "--reverse")) {
> -		revs->reverse ^= 1;
> +	} else if (starts_with(arg, "--reverse")) {
> +		if (!skip_prefix(arg, "--reverse=", &optarg)) {
> +			if (argc < 2) {
> +				revs->reverse = 1;
> +				return 1;
> +			} else {
> +				optarg = argv[1];
> +			}
> +		}

> +
> +		if (!strcmp(optarg, "after")) {
> +			revs->reverse = 1;
> +		} else if (!strcmp(optarg, "before")) {
> +			revs->reverse = 2;
> +		} else {
> +			revs->reverse = 1;
> +			return 1;
> +		}

> > I think I mean that
> > 
> >     git log --reverse --reverse
> > 
> > shows commits in the same order as "git log"; what should
> > 
> >     git log --reverse=after --reverse
> > 
> > do? Or what about preserving the behavior of the original "git log
> > --reverse --reverse," which I don't think is done here?
> 
> Yes, this is what I was getting at. Since it is no longer binary what
> would a double reverse mean? What if "--reverse=after --reverse=before"?
> How should that be handled?

> On Sat, Apr 18, 2026 at 06:47:35PM +0200, Mirko Faina wrote:
> 
> > @@ -2685,8 +2685,26 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> >  		else
> >  			git_log_output_encoding = xstrdup("");
> >  		return argcount;
> > -	} else if (!strcmp(arg, "--reverse")) {
> > -		revs->reverse ^= 1;
> > +	} else if (starts_with(arg, "--reverse")) {
> > +		if (!skip_prefix(arg, "--reverse=", &optarg)) {
> > +			if (argc < 2) {
> > +				revs->reverse = 1;
> > +				return 1;
> > +			} else {
> > +				optarg = argv[1];
> > +			}
> > +		}
> 
> It looks like you're trying to support "--reverse after" here, but don't
> do that. Flags with optional arguments must use the "stuck" form,
> "--reverse=after", which is covered in the "gitcli" manpage.

> That's to prevent "--reverse --foo" from being ambiguous. It looks like
> you try to limit that with the final "else" here:
> 
> > +
> > +		if (!strcmp(optarg, "after")) {
> > +			revs->reverse = 1;
> > +		} else if (!strcmp(optarg, "before")) {
> > +			revs->reverse = 2;
> > +		} else {
> > +			revs->reverse = 1;
> > +			return 1;
> > +		}
> 
> but that just makes things more complicated:
> 
>   - doing "git log --reverse=bogus" is silently accepted
> 
>   - trying to show a branch named "after" with "git log --reverse after"
>     has changed meanings
> 
> So I think you really just want to handle "--reverse=" separately from
> "--reverse", and the latter should behave as it always has.
> 
> -Peff

> On Sun, Apr 19, 2026 at 10:31:37PM +0200, Mirko Faina wrote:
> 
> > > I think I mean that
> > > 
> > >     git log --reverse --reverse
> > > 
> > > shows commits in the same order as "git log"; what should
> > > 
> > >     git log --reverse=after --reverse
> > > 
> > > do? Or what about preserving the behavior of the original "git log
> > > --reverse --reverse," which I don't think is done here?
> > 
> > Yes, this is what I was getting at. Since it is no longer binary what
> > would a double reverse mean? What if "--reverse=after --reverse=before"?
> > How should that be handled?
> 
> Yeah, I agree it gets weird, and I think it is OK if we don't try to
> combine before/after reverses (either making it an error, or using the
> usual last-one-wins to have "before" override "after" in this example).
> 
> But we should keep "--reverse --reverse" working as before, as there is
> no other way to countermand a previously-given reverse option, and
> because it has always worked.

> So combined with the earlier suggestions for using an enum and
> disallowing the un-stuck "--reverse after" form, we probably want
> something like (totally untested):
> 
> diff --git a/revision.c b/revision.c
> index 599b3a66c3..89a58a65b7 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2686,7 +2686,20 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>  			git_log_output_encoding = xstrdup("");
>  		return argcount;
>  	} else if (!strcmp(arg, "--reverse")) {
> -		revs->reverse ^= 1;
> +		/*
> +		 * This relies on "do not reverse" being the 0 value for our
> +		 * enum, and historical "reverse after" having value 1.
> +		 */
> +		revs->reverse = !revs->reverse;
> +	} else if (!strcmp(arg, "--no-reverse")) {
> +		revs->reverse = 0;
> +	} else if (skip_prefix(arg, "--reverse=", &optarg)) {
> +		if (!strcmp(optarg, "after"))
> +			revs->reverse = REVS_REVERSE_AFTER;
> +		else if (!strcmp(optarg, "before"))
> +			revs->reverse = REVS_REVERSE_BEFORE;
> +		else
> +			die(_("unknown value for --reverse: %s"), optarg);
>  	} else if (!strcmp(arg, "--children")) {
>  		revs->children.name = "children";
>  		revs->limited = 1;

> Note that your original also allowed --reverse-o-matic, which we
> probably don't want (and is fixed here).
> 
> I _think_ the negation from using "--reverse" after "--reverse=before"
> should be sensible here. And "--reverse=" with two different modes just
> overrides rather than trying to be clever. But you may want to
> double-check all of the combinations.
> 
> This would all be much easier if revision.c used parse-options, of
> course, which has all of these sorts of rules baked-in. But that's a
> much bigger conversion, and probably not something you want to make a
> prerequisite for your series. ;)

> > diff --git a/revision.c b/revision.c
> > index 599b3a66c3..89a58a65b7 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -2686,7 +2686,20 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> >  			git_log_output_encoding = xstrdup("");
> >  		return argcount;
> >  	} else if (!strcmp(arg, "--reverse")) {
> > -		revs->reverse ^= 1;
> > +		/*
> > +		 * This relies on "do not reverse" being the 0 value for our
> > +		 * enum, and historical "reverse after" having value 1.
> > +		 */
> > +		revs->reverse = !revs->reverse;
> > +	} else if (!strcmp(arg, "--no-reverse")) {
> > +		revs->reverse = 0;
> > +	} else if (skip_prefix(arg, "--reverse=", &optarg)) {
> > +		if (!strcmp(optarg, "after"))
> > +			revs->reverse = REVS_REVERSE_AFTER;
> > +		else if (!strcmp(optarg, "before"))
> > +			revs->reverse = REVS_REVERSE_BEFORE;
> > +		else
> > +			die(_("unknown value for --reverse: %s"), optarg);
> >  	} else if (!strcmp(arg, "--children")) {
> >  		revs->children.name = "children";
> >  		revs->limited = 1;
> 
> This unfortunately wouldn't work as the first condition is a prefix of
> the third, so no free copy-paste for me.
> 
> Will have separate parsing for omitted and explicit forms in v2.

> Tian Yuchen <cat@malon.dev> writes:
> 
>> I think the space complexity here could be reduced a little. After all,
>> since we’re only retrieving a few commits, there’s no need to load the
>> entire reversed commit history into memory.
> 
> Does "we're only retrieving a few commits" come from the fact that
> the command example is "log --reverse -3"?
> 
>   - What should happen when you give "git log --reverse=before"
>     without "--max-count=3"?

> It might be that the right way to look at this new feature is not
> that "we are changing where reverse is applied", but "count limit is
> applied much later than usual", which may mean at the UI level, it
> may not be good at the conceptual level to sell this as an extension
> to the "--reverse" option?  I dunno.

> Tian Yuchen <cat@malon.dev> writes:
> 
> > I think the space complexity here could be reduced a little. After all, 
> > since we’re only retrieving a few commits, there’s no need to load the 
> > entire reversed commit history into memory.
> 
> Does "we're only retrieving a few commits" come from the fact that
> the command example is "log --reverse -3"?  
> 
>  - What should happen when you give "git log --reverse=before"
>    without "--max-count=3"?
> 
>  - What should happen without "--max-count" but other limiting
>    options, like "--author=Tian" or "--min-parents=2"?
> 
> It might be that the right way to look at this new feature is not
> that "we are changing where reverse is applied", but "count limit is
> applied much later than usual", which may mean at the UI level, it
> may not be good at the conceptual level to sell this as an extension
> to the "--reverse" option?  I dunno.

> > But we should keep "--reverse --reverse" working as before, as there is
> > no other way to countermand a previously-given reverse option, and
> > because it has always worked.
> 
> What about a triple reverse? That would mean the original reverse choice
> is lost and it defaults to the historical "after", which I'm fine with,
> but this will need some extra caveat in the documentation :')

> > > > >    if (revs->reverse_output_stage) {
> > > > > +        if (revs->reverse == 2 && revs->max_count == 0)
> > > > > +            return NULL;
> > > > > +
> >
> > PS: something I spotted on a second read. [Ignoring reverse=after
> > mode] This hunk looks to me like a nice little optimization (return
> > nothing if we know max_count says we yield no commits). Of course, I
> > could see that being viable early in the function, right? When asking
> > get_revision for commits, if max_count is 0, just return NULL.
> >
> > For reverse=after mode, this condition is only true if the max_count
> > was 0 in the previous conditional, also, since we use max_count=-1
> > before iterating get_revision_internal. That means the original
> > max_count isn't touched. At any rate, it _seems_ to me that the whole
> > function could benefit from this optimization… but I wonder if it is
> > _necessary_ for correctness of reverse=after in some way that I'm not
> > seeing? Since the current version doesn't need the early bailout, why
> > does reverse=after?
>
> Just to clarify, "reverse = 2" is "--reverse=before" and not
> "--reverse=after".

> With "reverse = 2", the snippet of code you're referencing is not an
> optimization but a requirement for correctness. With "reverse = 1" we
> just keep the max_count as is and it's used by get_revision_internal()
> to stop if that limit is reached. What we find in 'reversed' are already
> just the commits we need to return.
>
> With "reverse = 2", we first set max_count to -1 and then retrieve the
> whole history, then we set max_count to its original value. Then we
> return the commits on each call of get_revision(). Now, unlike with
> "reverse = 1", we have the whole history in 'reversed', because of that
> we need to know when to stop. That's the reason we decrement max_count
> only for "reverse = 2" and why "max_count == 0" is checked only for
> "reverse = 2".

> > > > >        c = pop_commit(&revs->commits);
> > > > > +        if (revs->reverse == 2)
> > > > > +            revs->max_count--;
> > > >
> > > > Hm. Why do we decrement here? Again, not an area I’m familiar with, but a bit surprising.
> > >
> > > get_revision() (in revision.c) handles the reverse option and updates
> > > the "struct git_graph". get_revision() then calls
> > > get_revision_internal(), which handles commit boundaries and max_count,
> > > here is where it gets decreased. Since max_count gets decreased
> > > everytime get_revision_internal() is called, if we were to leave
> > > max_count as is before the walk (in get_revision() at line 4558), the
> > > walk would stop before reaching the root commit. This is why the current
> > > --reverse option is applied only after commit limiting options. So
> > > instead we set max_count at -1 walking the whole history and storing it
> > > in 'reversed'. Now we're in "reverse_output_stage = 1", and in this
> > > state we never call get_revision_internal() again, instead we pop
> > > commits from 'reversed'. Because of this we have to handle max_count
> > > outside get_revision_internal(), so we decrement it in the snippet of
> > > code you referenced.
> > >
> > > A bit verbose but hopefully it'll get my point across.
> >
> > I don't 100% follow, but I'm out of my depth :)
> >
> > I think I see that get_revision() effectively has 2 modes pertaining
> > to reverse: reverse and reverse output stage (the former falls
> > directly into the latter, though).
> >
> > After some setup, the reverse mode calls get_revision_internal() as
> > you said. That decrements max_count as a way of counting how many
> > commits we've seen through the loop, so if we asked for 5 we'd only
> > process 5 commits.
> >
> > Then we fall into the output stage mode, which pops a commit [1].
> >
> > With this patch, in reverse=after we disable max_count in the first
> > (reverse) mode, as you said. Ok: we get the whole (filtered) history
> > then, at which point we can now shrink. That makes sense.
> >
> > Then in the reverse output stage mode, we pretend to have one less
> > max_count. That's what I can't figure out. Is it because of the
> > pop_commit()? I guess I'm not totally seeing how that interacted with
> > the max_count in the original code: does the current code yield one
> > extra commit in get_revision_internal() ?
>
> I'm not sure I understand what you're referencing with "Then in the
> reverse output stage mode, we pretend to have one less max_count".
>
> If you're referring to line 4573, then...
>
> > You wrote that "we never call get_revision_internal() again," but I
> > don't see why that's true with this patch and not true before it.
> >
> > I do agree that _somebody_ has to handle max_count after
> > get_revision() returns with reverse=after. I'm just not sure what
> >
> >     if (revs->reverse == 2)
> >         revs->max_count--;
> >
> > is doing.
>
> ...we're not pretending we have fewer commits. Every subsequent call to
> get_revision() after the first call will never enter the branch at line
> 4548 and will only enter the branch at 4568. Everytime we pop a commit
> from 'reversed' we decrease max_count so we can limit only to the amount
> of commits the user wants.
>
> So, to recap, with "reverse = 2", on the first call to get_revision() we
> walk the whole history and store it in 'reversed' in reversed order and
> return the first commit.
> On subsequent calls to get_revision() we do not walk the history again,
> we simply return the commits that have been stored in 'reversed'.
> Everytime we pop a commit we have to decrease max_count, and we check
> againts max_count to know if we shouldn't return anymore commits (by
> returning NULL).

> > Of course if I'm the only one confused and others make sense of it,
> > that's ok, too.
>
> No, I completely understand. I did have to retouch the function a few
> times after writing the tests :P
>
> > [1]: I traced this to 498bcd3159 (rev-list: fix --reverse interaction
> > with --parents, 2008-08-29), but I can't fathom what the pop is doing
> > there.
>
> It's pretty much doing the same thing it does now, it's returning stored
> commits. In both versions, the initial setup when "revs->reverse" is
> true, becomes "dead code" after the first call.

> > > > > >        c = pop_commit(&revs->commits);
> > > > > > +        if (revs->reverse == 2)
> > > > > > +            revs->max_count--;
> > > > >
> > > > > Hm. Why do we decrement here? Again, not an area I’m familiar with, but a bit surprising.
> > > >
> > > > get_revision() (in revision.c) handles the reverse option and updates
> > > > the "struct git_graph". get_revision() then calls
> > > > get_revision_internal(), which handles commit boundaries and max_count,
> > > > here is where it gets decreased. Since max_count gets decreased
> > > > everytime get_revision_internal() is called, if we were to leave
> > > > max_count as is before the walk (in get_revision() at line 4558), the
> > > > walk would stop before reaching the root commit. This is why the current
> > > > --reverse option is applied only after commit limiting options. So
> > > > instead we set max_count at -1 walking the whole history and storing it
> > > > in 'reversed'. Now we're in "reverse_output_stage = 1", and in this
> > > > state we never call get_revision_internal() again, instead we pop
> > > > commits from 'reversed'. Because of this we have to handle max_count
> > > > outside get_revision_internal(), so we decrement it in the snippet of
> > > > code you referenced.
> > > >
> > > > A bit verbose but hopefully it'll get my point across.
> > >
> > > I don't 100% follow, but I'm out of my depth :)
> > >
> > > I think I see that get_revision() effectively has 2 modes pertaining
> > > to reverse: reverse and reverse output stage (the former falls
> > > directly into the latter, though).
> > >
> > > After some setup, the reverse mode calls get_revision_internal() as
> > > you said. That decrements max_count as a way of counting how many
> > > commits we've seen through the loop, so if we asked for 5 we'd only
> > > process 5 commits.
> > >
> > > Then we fall into the output stage mode, which pops a commit [1].
> > >
> > > With this patch, in reverse=after we disable max_count in the first
> > > (reverse) mode, as you said. Ok: we get the whole (filtered) history
> > > then, at which point we can now shrink. That makes sense.
> > >
> > > Then in the reverse output stage mode, we pretend to have one less
> > > max_count. That's what I can't figure out. Is it because of the
> > > pop_commit()? I guess I'm not totally seeing how that interacted with
> > > the max_count in the original code: does the current code yield one
> > > extra commit in get_revision_internal() ?
> >
> > I'm not sure I understand what you're referencing with "Then in the
> > reverse output stage mode, we pretend to have one less max_count".
> >
> > If you're referring to line 4573, then...
> >
> > > You wrote that "we never call get_revision_internal() again," but I
> > > don't see why that's true with this patch and not true before it.
> > >
> > > I do agree that _somebody_ has to handle max_count after
> > > get_revision() returns with reverse=after. I'm just not sure what
> > >
> > >     if (revs->reverse == 2)
> > >         revs->max_count--;
> > >
> > > is doing.
> >
> > ...we're not pretending we have fewer commits. Every subsequent call to
> > get_revision() after the first call will never enter the branch at line
> > 4548 and will only enter the branch at 4568. Everytime we pop a commit
> > from 'reversed' we decrease max_count so we can limit only to the amount
> > of commits the user wants.
> >
> > So, to recap, with "reverse = 2", on the first call to get_revision() we
> > walk the whole history and store it in 'reversed' in reversed order and
> > return the first commit.
> > On subsequent calls to get_revision() we do not walk the history again,
> > we simply return the commits that have been stored in 'reversed'.
> > Everytime we pop a commit we have to decrease max_count, and we check
> > againts max_count to know if we shouldn't return anymore commits (by
> > returning NULL).
> 
> …but I think this one does. I think what I missed is that in all
> "reverse" modes, get_revision() does some pre-computation and then
> yields one at a time the commits. In traditional "after" mode, the
> counting is done by get_revision_internal() [before reversal]. In the
> new mode, get_revision takes on that responsibility of
> get_revision_internal instead.
> 
> Hm. That suggests to me that get_revision's responsibilities are
> becoming complex. Might be worth some version of a refactor, but idk
> which.

> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index 2d195a1474..7244e85108 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -914,10 +914,16 @@ With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
>  avoid showing the commits from two parallel development track mixed
>  together.
>  
> -`--reverse`::
> -	Output the commits chosen to be shown (see 'Commit Limiting'
> -	section above) in reverse order. Cannot be combined with
> -	`--walk-reflogs`.
> +`--[no-]reverse[=(after|before)]`::
> +	Accepts `after` or `before`. Cannot be combined with
> +	`--walk-reflogs`. If `after`, output the commits chosen to be
> +	shown (see 'Commit Limiting' section above) in reverse order. If
> +	`before`, reverse the commits before filtering with `Commit
> +	Limiting` options. This option can be used multiple times, last
> +	one is applied. When the argument for `--reverse` is omitted, if
> +	the current state is in no reverse, it defaults to `after`. If
> +	it is in any reversed state, it restores the original ordering
> +	by removing the reverse state.

> On Wed, Apr 22, 2026 at 02:28:40AM +0200, Mirko Faina wrote:
> 
> > diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> > index 2d195a1474..7244e85108 100644
> > --- a/Documentation/rev-list-options.adoc
> > +++ b/Documentation/rev-list-options.adoc
> > @@ -914,10 +914,16 @@ With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
> >  avoid showing the commits from two parallel development track mixed
> >  together.
> >  
> > -`--reverse`::
> > -	Output the commits chosen to be shown (see 'Commit Limiting'
> > -	section above) in reverse order. Cannot be combined with
> > -	`--walk-reflogs`.
> > +`--[no-]reverse[=(after|before)]`::
> > +	Accepts `after` or `before`. Cannot be combined with
> > +	`--walk-reflogs`. If `after`, output the commits chosen to be
> > +	shown (see 'Commit Limiting' section above) in reverse order. If
> > +	`before`, reverse the commits before filtering with `Commit
> > +	Limiting` options. This option can be used multiple times, last
> > +	one is applied. When the argument for `--reverse` is omitted, if
> > +	the current state is in no reverse, it defaults to `after`. If
> > +	it is in any reversed state, it restores the original ordering
> > +	by removing the reverse state.
> 
> I think this is all correct, but I found the final sentences a bit hard
> to follow (especially the phrase "reversed state"). Let me take a stab
> at it.
> 
>   When multiple `--reverse=` options are given, the final option
>   overrides any previous options. The `--reverse` option (with no
>   specifier) behaves as `--reverse=after`, except that for historical
>   reasons it negates any previous reversed state (so `--reverse
>   --reverse` does nothing, nor does `--reverse=before --reverse`).
> 
> I dunno if that is any better, really. I hoped by mentioning "historical
> reasons" that excuses any weirdness, and readers interested in sane
> behavior can stop reading. ;)
> 
> So anyway, I offer it in case you find it useful or can pick out useful
> bits from it.

> 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

> 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"?

> If at all,
> then this "newest" and "oldest" must be a restriction that applies to
> --max-count in some way. Perhaps we need a --max-count-oldest option,
> then --reverse does not have to be touched at all, because it is still
> applied only after the set of commits to show has been determined.

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

> @@ -1882,6 +1882,72 @@ test_expect_success 'log --graph with --name-status' '
>  	test_cmp_graph --name-status tangle..reach
>  '
>  
> +cat >expect <<-\EOF
> +c3f451c Merge tag 'reach'
> +046b221 to remove
> +EOF
> +test_expect_success 'log --reverse --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse --reverse --reverse --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse --reverse --reverse --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse=after --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse=after --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +cat >expect <<-\EOF
> +3a2fdcb initial
> +f7dab8e second
> +EOF
> +
> +test_expect_success 'log --reverse=before --oneline --max-count=2' '
> +	test_when_finished rm actual &&
> +	git log --reverse=before --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +cat >expect <<-\EOF
> +046b221 to remove
> +c3f451c Merge tag 'reach'
> +EOF
> +
> +test_expect_success 'log --reverse --reverse --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse --reverse --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --reverse --no-reverse --oneline --max-count=2' '
> +	test_when_finished git reset --hard HEAD~1 &&
> +	touch to_remove &&
> +	git add to_remove &&
> +	git commit -m "to remove" &&
> +	git log --reverse --no-reverse --oneline --max-count=2 >actual &&
> +	test_cmp expect actual
> +'
> +
>  cat >expect <<-\EOF
>  * reach
>  |

>  		reversed = NULL;
> -		while ((c = get_revision_internal(revs)))
> -			commit_list_insert(c, &reversed);
> +		if (revs->reverse == REVERSE_BEFORE && max_count >= 0) {
> +			retrieve_with_window(revs, max_count, &reversed);
> +		} else {
> +			while ((c = get_revision_internal(revs)))
> +				commit_list_insert(c, &reversed);
> +		}

>> It might be that the right way to look at this new feature is not that
>> "we are changing where reverse is applied", but "count limit is applied
>> much later than usual"
>
> maybe --max-count-later as in max count is being applied later than
> usual? (either way the users will still need to reach for the man pages
> for clarifications).

> Teach get_revision() the --max-count-oldest option.
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
>  Documentation/rev-list-options.adoc |  3 ++
>  revision.c                          | 77 +++++++++++++++++++++++++++--
>  revision.h                          |  2 +
>  t/t4202-log.sh                      | 14 ++++++
>  4 files changed, 93 insertions(+), 3 deletions(-)

> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index 2d195a1474..736f34efab 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -18,6 +18,9 @@ ordering and formatting options, such as `--reverse`.
>  `--max-count=<number>`::
>  	Limit the output to _<number>_ commits.
>  
> +`--max-count-oldest=<number>`::
> +	Limit the output to the _<number>_ oldest commits.
> +
>  `--skip=<number>`::
>  	Skip _<number>_ commits before starting to show the commit output.
>  
> diff --git a/revision.c b/revision.c
> index 599b3a66c3..3aaa77ced5 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2339,10 +2339,24 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>  	}
>  
>  	if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
> +		if (revs->max_count_type == 1)
> +			die(_("can't use --max-count with --max-count-oldest"));
>  		revs->max_count = parse_count(optarg);
>  		revs->no_walk = 0;
> +		revs->max_count_type = 0;
>  		return argcount;
> +	} else if ((argcount = parse_long_opt("max-count-oldest", argv, &optarg))) {
> +		if (revs->max_count_type == 0 && revs->max_count != -1)
> +			die(_("can't use --max-count with --max-count-oldest"));
> +		if (revs->skip_count > 0)
> +			die(_("con't use --max-count-oldest with --skip"));
> +		revs->max_count = parse_count(optarg);
> +		revs->no_walk = 0;
> +		revs->max_count_type = 1;
> +		revs->max_count_stage = 0;
>  	} else if ((argcount = parse_long_opt("skip", argv, &optarg))) {
> +		if (revs->max_count_type == 1)
> +			die(_("con't use --max-count-oldest with --skip"));
>  		revs->skip_count = parse_count(optarg);
>  		return argcount;
>  	} else if ((*arg == '-') && isdigit(arg[1])) {
> @@ -4521,15 +4535,68 @@ static struct commit *get_revision_internal(struct rev_info *revs)
>  	return c;
>  }
>  
> +static void retrieve_oldest_commits(struct rev_info *revs,
> +				    struct commit_list **queue)
> +{
> +	struct commit *c;
> +	int max_count = revs->max_count;
> +	int queuei_count = 0;
> +	int queueo_count = 0;
> +	struct commit_list *queueo = NULL;
> +	struct commit_list *queuei = NULL;
> +	struct commit_list *reversed_queue = NULL;
> +
> +	revs->max_count = -1;
> +	while ((c = get_revision_internal(revs))) {
> +		c->object.flags &= ~SHOWN;
> +		commit_list_insert(c, &queuei);
> +		queuei_count++;
> +		while (queuei_count + queueo_count > max_count) {
> +			if (!queueo_count) {
> +				while (queuei_count > 0) {
> +					c = pop_commit(&queuei);
> +					queuei_count--;
> +					commit_list_insert(c, &queueo);
> +					queueo_count++;
> +				}
> +			}
> +			pop_commit(&queueo);
> +			queueo_count--;
> +		}
> +	}
> +
> +	while ((c = pop_commit(&queueo)))
> +		commit_list_insert(c, &reversed_queue);
> +	while ((c = pop_commit(&queuei)))
> +		commit_list_insert(c, &queueo);
> +	while ((c = pop_commit(&queueo)))
> +		commit_list_insert(c, &reversed_queue);
> +
> +	while ((c = pop_commit(&reversed_queue)))
> +		commit_list_insert(c, queue);
> +}
> +
>  struct commit *get_revision(struct rev_info *revs)
>  {
>  	struct commit *c;
>  	struct commit_list *reversed;
> +	struct commit_list *queue = NULL;
> +
> +	if (revs->max_count_type == 1 && !revs->max_count_stage) {
> +		retrieve_oldest_commits(revs, &queue);
> +		commit_list_free(revs->commits);
> +		revs->commits = queue;
> +		revs->max_count_stage = 1;
> +	}
>  
>  	if (revs->reverse) {
>  		reversed = NULL;
> -		while ((c = get_revision_internal(revs)))
> -			commit_list_insert(c, &reversed);
> +		if (revs->max_count_type == 1)
> +			while ((c = pop_commit(&revs->commits)))
> +				commit_list_insert(c, &reversed);
> +		else
> +			while ((c = get_revision_internal(revs)))
> +				commit_list_insert(c, &reversed);
>  		commit_list_free(revs->commits);
>  		revs->commits = reversed;
>  		revs->reverse = 0;
> @@ -4543,7 +4610,11 @@ struct commit *get_revision(struct rev_info *revs)
>  		return c;
>  	}
>  
> -	c = get_revision_internal(revs);
> +	if (revs->max_count_stage)
> +		c = pop_commit(&revs->commits);
> +	else
> +		c = get_revision_internal(revs);
> +
>  	if (c && revs->graph)
>  		graph_update(revs->graph, c);
>  	if (!c) {
> diff --git a/revision.h b/revision.h
> index 584f1338b5..e157463cb1 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -309,6 +309,8 @@ struct rev_info {
>  	/* special limits */
>  	int skip_count;
>  	int max_count;
> +	unsigned int max_count_type:1;
> +	unsigned int max_count_stage:1;
>  	timestamp_t max_age;
>  	timestamp_t max_age_as_filter;
>  	timestamp_t min_age;
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 05cee9e41b..668c231cf1 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -1882,6 +1882,20 @@ test_expect_success 'log --graph with --name-status' '
>  	test_cmp_graph --name-status tangle..reach
>  '
>  
> +test_expect_success 'log --max-count-oldest=3 --oneline' '
> +	test_when_finished rm expect &&
> +	git log --oneline | tail -n3 >expect &&
> +	git log --oneline --max-count-oldest=3 >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'log --max-count-oldest=3 --reverse --oneline' '
> +	test_when_finished rm expect &&
> +	git log --oneline | tail -n3 | tac >expect &&
> +	git log --oneline --max-count-oldest=3 --reverse >actual &&
> +	test_cmp expect actual
> +'
> +
>  cat >expect <<-\EOF
>  * reach
>  |

> Mirko Faina <mroik@delayed.space> writes:
> 
> > --max-count is a commit limiting option sets a maximum amount of commits
> > to be shown. If a user wants to see only the first N commits of the
> > history (the oldest commits) they'd have to combine --max-count with
> > --skip. This is not very user-friendly.
> 
> To use "--skip=<n>" for this purose, you'd need to know how many
> records are going to be omitted to begin with, but that means you'd
> run the command without count limitation once only to find out how
> many records there are.  "not very user-friendly" sounds like an
> understatement of the year.
> 
> They can do with something silly like
> 
>     git rev-list ... |
>     tail -n N |
>     xargs -n1 git show ...
> 
> and that does count as "not very user-friendly", I would think.

> > Teach get_revision() the --max-count-oldest option.
> >
> > Signed-off-by: Mirko Faina <mroik@delayed.space>
> > ---
> >  Documentation/rev-list-options.adoc |  3 ++
> >  revision.c                          | 77 +++++++++++++++++++++++++++--
> >  revision.h                          |  2 +
> >  t/t4202-log.sh                      | 14 ++++++
> >  4 files changed, 93 insertions(+), 3 deletions(-)
> 
> It looks like this needs measurably smaller damage to the codebase
> than the other --reverse=before approach ;-).

> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
> 
>     git log $(git rev-list HEAD | tail -n N | head -n 1)
> 
> This is not very user-friendly.
> 
> Teach get_revision() the --max-count-oldest option.
> 
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
> Since v5 I've reworded the commit message and rewrote the docs for
> --max-count-oldest to be clearer on its functionality.
> 
>  Documentation/rev-list-options.adoc |  5 ++
>  revision.c                          | 77 +++++++++++++++++++++++++++--
>  revision.h                          |  2 +
>  t/t4202-log.sh                      | 14 ++++++
>  4 files changed, 95 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index 2d195a1474..9f857cabcc 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -18,6 +18,11 @@ ordering and formatting options, such as `--reverse`.
>  `--max-count=<number>`::
>     Limit the output to _<number>_ commits.
>  
> +`--max-count-oldest=<number>`::
> +   Just like `--max-count=<number>`, it limits the output to _<number>_
> +   commits. But instead of limiting to the first _<number>_ commits it
> +   limits to the last _<number>_ commits.
> +

>  `--skip=<number>`::
>     Skip _<number>_ commits before starting to show the commit output.
>  
> diff --git a/revision.c b/revision.c
> index 599b3a66c3..3aaa77ced5 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2339,10 +2339,24 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>     }
>  
>     if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
> +       if (revs->max_count_type == 1)
> +           die(_("can't use --max-count with --max-count-oldest"));

>         revs->max_count = parse_count(optarg);
>         revs->no_walk = 0;
> +       revs->max_count_type = 0;
>         return argcount;
> +   } else if ((argcount = parse_long_opt("max-count-oldest", argv, &optarg))) {
> +       if (revs->max_count_type == 0 && revs->max_count != -1)
> +           die(_("can't use --max-count with --max-count-oldest"));
> +       if (revs->skip_count > 0)
> +           die(_("con't use --max-count-oldest with --skip"));
> +       revs->max_count = parse_count(optarg);
> +       revs->no_walk = 0;
> +       revs->max_count_type = 1;
> +       revs->max_count_stage = 0;
>     } else if ((argcount = parse_long_opt("skip", argv, &optarg))) {
> +       if (revs->max_count_type == 1)
> +           die(_("con't use --max-count-oldest with --skip"));
>         revs->skip_count = parse_count(optarg);
>         return argcount;
>     } else if ((*arg == '-') && isdigit(arg[1])) {
> @@ -4521,15 +4535,68 @@ static struct commit *get_revision_internal(struct rev_info *revs)
>     return c;
>  }
>  
> +static void retrieve_oldest_commits(struct rev_info *revs,
> +                   struct commit_list **queue)
> +{
> +   struct commit *c;
> +   int max_count = revs->max_count;
> +   int queuei_count = 0;
> +   int queueo_count = 0;
> +   struct commit_list *queueo = NULL;
> +   struct commit_list *queuei = NULL;
> +   struct commit_list *reversed_queue = NULL;
> +
> +   revs->max_count = -1;
> +   while ((c = get_revision_internal(revs))) {
> +       c->object.flags &= ~SHOWN;
> +       commit_list_insert(c, &queuei);
> +       queuei_count++;
> +       while (queuei_count + queueo_count > max_count) {
> +           if (!queueo_count) {
> +               while (queuei_count > 0) {
> +                   c = pop_commit(&queuei);
> +                   queuei_count--;
> +                   commit_list_insert(c, &queueo);
> +                   queueo_count++;
> +               }
> +           }
> +           pop_commit(&queueo);
> +           queueo_count--;
> +       }
> +   }
> +
> +   while ((c = pop_commit(&queueo)))
> +       commit_list_insert(c, &reversed_queue);
> +   while ((c = pop_commit(&queuei)))
> +       commit_list_insert(c, &queueo);
> +   while ((c = pop_commit(&queueo)))
> +       commit_list_insert(c, &reversed_queue);
> +
> +   while ((c = pop_commit(&reversed_queue)))
> +       commit_list_insert(c, queue);
> +}
> +
>  struct commit *get_revision(struct rev_info *revs)
>  {
>     struct commit *c;
>     struct commit_list *reversed;
> +   struct commit_list *queue = NULL;
> +
> +   if (revs->max_count_type == 1 && !revs->max_count_stage) {
> +       retrieve_oldest_commits(revs, &queue);
> +       commit_list_free(revs->commits);
> +       revs->commits = queue;
> +       revs->max_count_stage = 1;
> +   }
>  
>     if (revs->reverse) {
>         reversed = NULL;
> -       while ((c = get_revision_internal(revs)))
> -           commit_list_insert(c, &reversed);
> +       if (revs->max_count_type == 1)
> +           while ((c = pop_commit(&revs->commits)))
> +               commit_list_insert(c, &reversed);
> +       else
> +           while ((c = get_revision_internal(revs)))
> +               commit_list_insert(c, &reversed);
>         commit_list_free(revs->commits);
>         revs->commits = reversed;
>         revs->reverse = 0;

> @@ -4543,7 +4610,11 @@ struct commit *get_revision(struct rev_info *revs)
>         return c;
>     }
>  
> -   c = get_revision_internal(revs);
> +   if (revs->max_count_stage)
> +       c = pop_commit(&revs->commits);
> +   else
> +       c = get_revision_internal(revs);
> +
>     if (c && revs->graph)
>         graph_update(revs->graph, c);
>     if (!c) {
> diff --git a/revision.h b/revision.h
> index 584f1338b5..e157463cb1 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -309,6 +309,8 @@ struct rev_info {
>     /* special limits */
>     int skip_count;
>     int max_count;
> +   unsigned int max_count_type:1;
> +   unsigned int max_count_stage:1;
>     timestamp_t max_age;
>     timestamp_t max_age_as_filter;
>     timestamp_t min_age;

> > +`--max-count-oldest=<number>`::
> > +   Just like `--max-count=<number>`, it limits the output to _<number>_
> > +   commits. But instead of limiting to the first _<number>_ commits it
> > +   limits to the last _<number>_ commits.
> > +
> 
> "Just like --max-count" is a surprising addendum in this sentence,
> because the only thing they have in common is the limiting of commits,
> which it repeats anyway. It's more like "Unlike --max-count, limits the
> output to _<number>_ last commits."

> >  `--skip=<number>`::
> >     Skip _<number>_ commits before starting to show the commit output.
> >  
> > diff --git a/revision.c b/revision.c
> > index 599b3a66c3..3aaa77ced5 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -2339,10 +2339,24 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> >     }
> >  
> >     if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
> > +       if (revs->max_count_type == 1)
> > +           die(_("can't use --max-count with --max-count-oldest"));
> 
> To help translators, the usual pattern is to say (here and later)
> 
> 	die(_("options '%s' and '%s' cannot be used together"),
> 		"--max-count", "--max-count-oldest");

> > @@ -4521,15 +4535,68 @@ static struct commit *get_revision_internal(struct rev_info *revs)
> >     return c;
> >  }
> >  
> > +static void retrieve_oldest_commits(struct rev_info *revs,
> > +                   struct commit_list **queue)
> > +{
> > +   struct commit *c;
> > +   int max_count = revs->max_count;
> > +   int queuei_count = 0;
> > +   int queueo_count = 0;
> > +   struct commit_list *queueo = NULL;
> > +   struct commit_list *queuei = NULL;
> > +   struct commit_list *reversed_queue = NULL;
> > +
> > +   revs->max_count = -1;
> > +   while ((c = get_revision_internal(revs))) {
> > +       c->object.flags &= ~SHOWN;
> > +       commit_list_insert(c, &queuei);
> > +       queuei_count++;
> > +       while (queuei_count + queueo_count > max_count) {
> > +           if (!queueo_count) {
> > +               while (queuei_count > 0) {
> > +                   c = pop_commit(&queuei);
> > +                   queuei_count--;
> > +                   commit_list_insert(c, &queueo);
> > +                   queueo_count++;
> > +               }
> > +           }
> > +           pop_commit(&queueo);
> > +           queueo_count--;
> > +       }
> > +   }
> > +
> > +   while ((c = pop_commit(&queueo)))
> > +       commit_list_insert(c, &reversed_queue);
> > +   while ((c = pop_commit(&queuei)))
> > +       commit_list_insert(c, &queueo);
> > +   while ((c = pop_commit(&queueo)))
> > +       commit_list_insert(c, &reversed_queue);
> > +
> > +   while ((c = pop_commit(&reversed_queue)))
> > +       commit_list_insert(c, queue);
> > +}
> > +
> >  struct commit *get_revision(struct rev_info *revs)
> >  {
> >     struct commit *c;
> >     struct commit_list *reversed;
> > +   struct commit_list *queue = NULL;
> > +
> > +   if (revs->max_count_type == 1 && !revs->max_count_stage) {
> > +       retrieve_oldest_commits(revs, &queue);
> > +       commit_list_free(revs->commits);
> > +       revs->commits = queue;
> > +       revs->max_count_stage = 1;
> > +   }
> >  
> >     if (revs->reverse) {
> >         reversed = NULL;
> > -       while ((c = get_revision_internal(revs)))
> > -           commit_list_insert(c, &reversed);
> > +       if (revs->max_count_type == 1)
> > +           while ((c = pop_commit(&revs->commits)))
> > +               commit_list_insert(c, &reversed);
> > +       else
> > +           while ((c = get_revision_internal(revs)))
> > +               commit_list_insert(c, &reversed);
> >         commit_list_free(revs->commits);
> >         revs->commits = reversed;
> >         revs->reverse = 0;
> 
> I would have expected that this kind of commit counting is handled at
> the same spot where --max-count is handled, i.e., in
> get_revision_internal(). It could make a difference in combination with
> sorting options, --boundary, and --graph. The goal is that --max-count
> and --max-count-oldest behave the same in this regard. (But I am in no
> way an expert of the revision walker.)

>> BTW, this makes me think whether this kind of limiting could be
>> triggered by a negative argument to --max-count.
>
> Would be a good idea if it weren't for the fact that --max-count < 0 has
> for a long time acted like no max count. I'd imagine many could be
> asssuming this behaviour in their scripts.

> Mirko Faina <mroik@delayed.space> writes:
> 
> >> BTW, this makes me think whether this kind of limiting could be
> >> triggered by a negative argument to --max-count.
> >
> > Would be a good idea if it weren't for the fact that --max-count < 0 has
> > for a long time acted like no max count. I'd imagine many could be
> > asssuming this behaviour in their scripts.
> 
> Many?  I am not sure.  
> 
> What do these script try to achieve by having "--max-count=-1"?  It
> would be to defeat --max-count=<n> coming from elsewhere, but where?

> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to combine --max-count with
> --skip. This is not very user-friendly.
> ...
> +test_expect_success 'log --max-count-oldest=3 --reverse --oneline' '
> +	test_when_finished rm expect &&
> +	git log --oneline | tail -n3 | tac >expect &&
> +	git log --oneline --max-count-oldest=3 --reverse >actual &&
> +	test_cmp expect actual
> +'

> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
> 
>     git log $(git rev-list HEAD | tail -n N | head -n 1)
> 
> This is not very user-friendly.
> 
> Teach get_revision() the --max-count-oldest option.
> 
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
> Since v5 I've reworded the commit message and rewrote the docs for
> --max-count-oldest to be clearer on its functionality.
> 
>  Documentation/rev-list-options.adoc |  5 ++
>  revision.c                          | 77 +++++++++++++++++++++++++++--
>  revision.h                          |  2 +
>  t/t4202-log.sh                      | 14 ++++++
>  4 files changed, 95 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/rev-list-options.adoc
> b/Documentation/rev-list-options.adoc index 2d195a1474..9f857cabcc 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -18,6 +18,11 @@ ordering and formatting options, such as `--reverse`.
>  `--max-count=<number>`::
>     Limit the output to _<number>_ commits.
> 
> +`--max-count-oldest=<number>`::
> +   Just like `--max-count=<number>`, it limits the output to _<number>_
> +   commits. But instead of limiting to the first _<number>_ commits it
> +   limits to the last _<number>_ commits.
> +

>  `--skip=<number>`::
>     Skip _<number>_ commits before starting to show the commit output.
> 
> diff --git a/revision.c b/revision.c
> index 599b3a66c3..3aaa77ced5 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2339,10 +2339,24 @@ static int handle_revision_opt(struct rev_info 

> argc, const char **arg }
> 
>     if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
> +       if (revs->max_count_type == 1)
> +           die(_("can't use --max-count with --max-count-oldest"));
>         revs->max_count = parse_count(optarg);
>         revs->no_walk = 0;
> +       revs->max_count_type = 0;
>         return argcount;
> +   } else if ((argcount = parse_long_opt("max-count-oldest", argv, 

> +       revs->max_count = parse_count(optarg);
> +       revs->no_walk = 0;
> +       revs->max_count_type = 1;
> +       revs->max_count_stage = 0;
>     } else if ((argcount = parse_long_opt("skip", argv, &optarg))) {
> +       if (revs->max_count_type == 1)
> +           die(_("con't use --max-count-oldest with --skip"));

> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
>
>     git log $(git rev-list HEAD | tail -n N | head -n 1)
>
> This is not very user-friendly.
>
> Teach get_revision() the --max-count-oldest option.
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
> Since v5 I've reworded the commit message and rewrote the docs for
> --max-count-oldest to be clearer on its functionality.
>
>  Documentation/rev-list-options.adoc |  5 ++
>  revision.c                          | 77 +++++++++++++++++++++++++++--
>  revision.h                          |  2 +
>  t/t4202-log.sh                      | 14 ++++++
>  4 files changed, 95 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index 2d195a1474..9f857cabcc 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -18,6 +18,11 @@ ordering and formatting options, such as `--reverse`.
>  `--max-count=<number>`::
>     Limit the output to _<number>_ commits.
>  
> +`--max-count-oldest=<number>`::
> +   Just like `--max-count=<number>`, it limits the output to _<number>_
> +   commits. But instead of limiting to the first _<number>_ commits it
> +   limits to the last _<number>_ commits.
> +
>  `--skip=<number>`::
>     Skip _<number>_ commits before starting to show the commit output.

> diff --git a/revision.c b/revision.c
> index 599b3a66c3..3aaa77ced5 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2339,10 +2339,24 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>     }
>  
>     if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
> +       if (revs->max_count_type == 1)
> +           die(_("can't use --max-count with --max-count-oldest"));
>         revs->max_count = parse_count(optarg);
>         revs->no_walk = 0;
> +       revs->max_count_type = 0;
>         return argcount;
> +   } else if ((argcount = parse_long_opt("max-count-oldest", argv, &optarg))) {
> +       if (revs->max_count_type == 0 && revs->max_count != -1)
> +           die(_("can't use --max-count with --max-count-oldest"));
> +       if (revs->skip_count > 0)
> +           die(_("con't use --max-count-oldest with --skip"));
> +       revs->max_count = parse_count(optarg);
> +       revs->no_walk = 0;
> +       revs->max_count_type = 1;
> +       revs->max_count_stage = 0;
>     } else if ((argcount = parse_long_opt("skip", argv, &optarg))) {
> +       if (revs->max_count_type == 1)
> +           die(_("con't use --max-count-oldest with --skip"));
>         revs->skip_count = parse_count(optarg);
>         return argcount;
>     } else if ((*arg == '-') && isdigit(arg[1])) {
> @@ -4521,15 +4535,68 @@ static struct commit *get_revision_internal(struct rev_info *revs)
>     return c;
>  }
>  
> +static void retrieve_oldest_commits(struct rev_info *revs,
> +                   struct commit_list **queue)
> +{
> +   struct commit *c;
> +   int max_count = revs->max_count;
> +   int queuei_count = 0;
> +   int queueo_count = 0;
> +   struct commit_list *queueo = NULL;
> +   struct commit_list *queuei = NULL;
> +   struct commit_list *reversed_queue = NULL;
> +
> +   revs->max_count = -1;
> +   while ((c = get_revision_internal(revs))) {
> +       c->object.flags &= ~SHOWN;
> +       commit_list_insert(c, &queuei);
> +       queuei_count++;
> +       while (queuei_count + queueo_count > max_count) {
> +           if (!queueo_count) {
> +               while (queuei_count > 0) {
> +                   c = pop_commit(&queuei);
> +                   queuei_count--;
> +                   commit_list_insert(c, &queueo);
> +                   queueo_count++;
> +               }
> +           }
> +           pop_commit(&queueo);
> +           queueo_count--;
> +       }
> +   }
> +
> +   while ((c = pop_commit(&queueo)))
> +       commit_list_insert(c, &reversed_queue);
> +   while ((c = pop_commit(&queuei)))
> +       commit_list_insert(c, &queueo);
> +   while ((c = pop_commit(&queueo)))
> +       commit_list_insert(c, &reversed_queue);
> +
> +   while ((c = pop_commit(&reversed_queue)))
> +       commit_list_insert(c, queue);
> +}
> +
>  struct commit *get_revision(struct rev_info *revs)
>  {
>     struct commit *c;
>     struct commit_list *reversed;
> +   struct commit_list *queue = NULL;
> +
> +   if (revs->max_count_type == 1 && !revs->max_count_stage) {
> +       retrieve_oldest_commits(revs, &queue);
> +       commit_list_free(revs->commits);
> +       revs->commits = queue;
> +       revs->max_count_stage = 1;
> +   }
>  
>     if (revs->reverse) {
>         reversed = NULL;
> -       while ((c = get_revision_internal(revs)))
> -           commit_list_insert(c, &reversed);
> +       if (revs->max_count_type == 1)
> +           while ((c = pop_commit(&revs->commits)))
> +               commit_list_insert(c, &reversed);
> +       else
> +           while ((c = get_revision_internal(revs)))
> +               commit_list_insert(c, &reversed);
>         commit_list_free(revs->commits);
>         revs->commits = reversed;
>         revs->reverse = 0;
> @@ -4543,7 +4610,11 @@ struct commit *get_revision(struct rev_info *revs)
>         return c;
>     }
>  
> -   c = get_revision_internal(revs);
> +   if (revs->max_count_stage)
> +       c = pop_commit(&revs->commits);
> +   else
> +       c = get_revision_internal(revs);
> +
>     if (c && revs->graph)
>         graph_update(revs->graph, c);
>     if (!c) {
> diff --git a/revision.h b/revision.h
> index 584f1338b5..e157463cb1 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -309,6 +309,8 @@ struct rev_info {
>     /* special limits */
>     int skip_count;
>     int max_count;
> +   unsigned int max_count_type:1;
> +   unsigned int max_count_stage:1;
>     timestamp_t max_age;
>     timestamp_t max_age_as_filter;
>     timestamp_t min_age;
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 05cee9e41b..668c231cf1 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -1882,6 +1882,20 @@ test_expect_success 'log --graph with --name-status' '
>     test_cmp_graph --name-status tangle..reach
>  '
>  
> +test_expect_success 'log --max-count-oldest=3 --oneline' '
> +   test_when_finished rm expect &&
> +   git log --oneline | tail -n3 >expect &&
> +   git log --oneline --max-count-oldest=3 >actual &&
> +   test_cmp expect actual
> +'
> +
> +test_expect_success 'log --max-count-oldest=3 --reverse --oneline' '
> +   test_when_finished rm expect &&
> +   git log --oneline | tail -n3 | tac >expect &&
> +   git log --oneline --max-count-oldest=3 --reverse >actual &&
> +   test_cmp expect actual
> +'
> +
>  cat >expect <<-\EOF
>  * reach
>  |

> Mirko Faina <mroik@delayed.space> writes:
> 
> > --max-count is a commit limiting option sets a maximum amount of commits
> > to be shown. If a user wants to see only the first N commits of the
> > history (the oldest commits) they'd have to combine --max-count with
> > --skip. This is not very user-friendly.
> > ...
> > +test_expect_success 'log --max-count-oldest=3 --reverse --oneline' '
> > +	test_when_finished rm expect &&
> > +	git log --oneline | tail -n3 | tac >expect &&
> > +	git log --oneline --max-count-oldest=3 --reverse >actual &&
> > +	test_cmp expect actual
> > +'
> 
> "tac" is not portable, and breaks macOS CI jobs.
> 
>   https://github.com/git/git/actions/runs/25591146540/job/75128929633#step:4:2058
> 
> Wouldn't
> 
>   git log --oneline --reverse | head -n3 >expect
> 
> be equivalent?

> On Tuesday, 5 May 2026 23:54:56 CEST Mirko Faina wrote:
> > --max-count is a commit limiting option sets a maximum amount of commits
> > to be shown. If a user wants to see only the first N commits of the
> > history (the oldest commits) they'd have to do something like
> > 
> >     git log $(git rev-list HEAD | tail -n N | head -n 1)
> > 
> > This is not very user-friendly.
> > 
> > Teach get_revision() the --max-count-oldest option.
> > 
> > Signed-off-by: Mirko Faina <mroik@delayed.space>
> > ---
> > Since v5 I've reworded the commit message and rewrote the docs for
> > --max-count-oldest to be clearer on its functionality.
> > 
> >  Documentation/rev-list-options.adoc |  5 ++
> >  revision.c                          | 77 +++++++++++++++++++++++++++--
> >  revision.h                          |  2 +
> >  t/t4202-log.sh                      | 14 ++++++
> >  4 files changed, 95 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/rev-list-options.adoc
> > b/Documentation/rev-list-options.adoc index 2d195a1474..9f857cabcc 100644
> > --- a/Documentation/rev-list-options.adoc
> > +++ b/Documentation/rev-list-options.adoc
> > @@ -18,6 +18,11 @@ ordering and formatting options, such as `--reverse`.
> >  `--max-count=<number>`::
> >     Limit the output to _<number>_ commits.
> > 
> > +`--max-count-oldest=<number>`::
> > +   Just like `--max-count=<number>`, it limits the output to _<number>_
> > +   commits. But instead of limiting to the first _<number>_ commits it
> > +   limits to the last _<number>_ commits.
> > +
> 
> Putting aside the discussion of --max-count=<neg-value> vs --max-count-
> oldest=<value>, I do not think that defining --max-count-old with respect with 
> --max-count is legible. It would be better to refine the definition of --max-
> count (i.e. "Limit the output to the _<number>_ first commits") and just 
> define --max-count-oldest on its own in the same manner. Referring to another 
> entry is only practicable when it avoids repeating a long explanation. 
> Otherwise, each entry's explanation should be as self-contained as possible.

> >  `--skip=<number>`::
> >     Skip _<number>_ commits before starting to show the commit output.
> > 
> > diff --git a/revision.c b/revision.c
> > index 599b3a66c3..3aaa77ced5 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -2339,10 +2339,24 @@ static int handle_revision_opt(struct rev_info 
> *revs, int
> > argc, const char **arg }
> > 
> >     if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
> > +       if (revs->max_count_type == 1)
> > +           die(_("can't use --max-count with --max-count-oldest"));
> >         revs->max_count = parse_count(optarg);
> >         revs->no_walk = 0;
> > +       revs->max_count_type = 0;
> >         return argcount;
> > +   } else if ((argcount = parse_long_opt("max-count-oldest", argv, 
> &optarg))) {
> > +       if (revs->max_count_type == 0 && revs->max_count != -1)
> > +           die(_("can't use --max-count with --max-count-oldest"));
> > +       if (revs->skip_count > 0)
> > +           die(_("con't use --max-count-oldest with --skip"));
> 
> Typo here (con't → can't). In any case, please prefer 
> die_for_incompatible_opt2, to uniformize the messages and limit the number of 
> translation strings.

> > +       revs->max_count = parse_count(optarg);
> > +       revs->no_walk = 0;
> > +       revs->max_count_type = 1;
> > +       revs->max_count_stage = 0;
> >     } else if ((argcount = parse_long_opt("skip", argv, &optarg))) {
> > +       if (revs->max_count_type == 1)
> > +           die(_("con't use --max-count-oldest with --skip"));
> 
> ditto

> >         revs->skip_count = parse_count(optarg);
> >         return argcount;
> >     } else if ((*arg == '-') && isdigit(arg[1])) {
> > @@ -4521,15 +4535,68 @@ static struct commit *get_revision_internal(struct 
> rev_info
> > *revs) return c;
> >  }
> > 

> Saving this message to a file and grepping for a tab finds nothing,
> which indicates that the patch seems to be unsalvageably whitespace
> broken, given that most of the context lines should use tabs for
> indent.
> 
> What did you do differently this time?  The previous rounds did not
> have this problem.

> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
> 
>     git log $(git rev-list HEAD | tail -n N | head -n 1)
> 
> This is not very user-friendly.
> 
> Teach get_revision() the --max-count-oldest option.
> 
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
>  Documentation/rev-list-options.adoc |   5 +-
>  revision.c                          | 111 +++++++++++++++++++++++++++-
>  revision.h                          |   2 +
>  t/t4202-log.sh                      |  41 ++++++++++
>  4 files changed, 155 insertions(+), 4 deletions(-)

> Mirko Faina <mroik@delayed.space> writes:
> 
> > +		 * graph_update() as it doesn't do the actualy printing, we'd
> 
> "actually"?

> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
>
>     git log $(git rev-list HEAD | tail -n N | head -n 1)
>
> This is not very user-friendly.
>
> Teach get_revision() the --max-count-oldest option.
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---

> Mirko Faina <mroik@delayed.space> writes:
> 
> > --max-count is a commit limiting option sets a maximum amount of commits
> > to be shown. If a user wants to see only the first N commits of the
> > history (the oldest commits) they'd have to do something like
> >
> >     git log $(git rev-list HEAD | tail -n N | head -n 1)
> >
> > This is not very user-friendly.
> >
> > Teach get_revision() the --max-count-oldest option.
> >
> > Signed-off-by: Mirko Faina <mroik@delayed.space>
> > ---
> 
> This breaks CI
> 
>   https://github.com/git/git/actions/runs/26138986677/job/76880268854#step:4:2072
> 
> Squash something like this to fix.
> 
> --- >8 ---
> Subject: [PATCH] SQUASH??? test portability and other fixes
> 
> * "test_when_finished" should use "rm -f", not an error-detecting
>   "rm", as the execution may not have reached to the point to create
>   the "actual" file it is removing.
> 
> * Do not hide exit status of "git log" by piping its output into
>   another process.
> 
> * Do not expect output of "wc -l" is portable.  macOS puts extra
>   whitespaces in front, while GNU/Linux does not.
> ---
>  t/t4202-log.sh | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)

> On Wed, May 20, 2026 at 03:02:34PM +0900, Junio C Hamano wrote:
>> 
>> This breaks CI
>> 
>>   https://github.com/git/git/actions/runs/26138986677/job/76880268854#step:4:2072
>> 
>> Squash something like this to fix.
>>  ...
>
> Sorry about that. And thank you for the fix.