Re: [PATCH v6] revision.c: implement --max-count-oldest

From: Mirko Faina <mroik@delayed.space>
Date: May 8, 2026, 00:09 UTC
Message-ID: <af0kZUczSPJrQcU6@exploit>
In-Reply-To: <87o6ireftj.fsf@gitster.g>

On Thu, May 07, 2026 at 06:20:40PM +0900, Junio C Hamano wrote:

Show 13 quoted lines

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

It's not necessarely to defeat a previous use of --max-count. If I know that --max-count behaves in as certain way, in this case the same as not having it when below 0, I can always have it in the command that I have to run and just work with the argument (of course one would do this only if it is easier to work with just the argument). That way I don't have to conditionally add the option if it has to be enabled. Something like

	N=should_use_max_count_and_if_so_much_to_limit
	git rev-list --max-count=$N

Of course these script make use of behaviour that is not documented and might not even be intended, so really their fault if it breaks.

This has been the behaviour of --max-count for a long time so I'm assuming that there is a possibility that it will break many scripts. But like I said, their fault if it breaks, if you think its not that widespread I'll get rid of --max-count-oldest.