Re: [PATCH] revision.c: implement --reverse=before for walks

From: Mirko Faina <mroik@delayed.space>
Date: Apr 20, 2026, 23:50 UTC
Message-ID: <aea3Kun-XxGJMesz@exploit>
In-Reply-To: <xmqqv7dlr4yz.fsf@gitster.g>

On Mon, Apr 20, 2026 at 09:06:44AM -0700, Junio C Hamano wrote:

Show 20 quoted lines

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

I'm not sure about that. The way max_count actually interacts with --reverse in the code is an implementation detail that the user doesn't need to worry about. It should be fine to tell the user that this feature is an extention of how --reverse behaves. Regarding "Commit Limiting options", we already tell the user

	Note that these are applied before commit ordering and formatting
	options, such as --reverse.

so explaining to the user that this new feature acts on reverse's behaviour might be easier (and not necessarily wrong on a conceptual level). I find "you can choose to apply reverse before any commit limiting option" easier to understand than "--max-count can be applied last, or before reverse but after all other Commit Limiting options".