Re: [PATCH 12/12] builtin/commit-graph.c: introduce '--max-new-filters=<n>'
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 11, 2020, 19:31 UTC
- Message-ID
- <xmqqft7onm9s.fsf@gitster.c.googlers.com>
- In-Reply-To
- <20200911175216.GA2693949@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 16 quoted lines
> I wondered about having a user-facing "-1" here. My gut feeling is that > we usually use "0" to mean "no limit" in other places, and it probably > make sense to be consistent. It does look like we use both, though, and > I'm having trouble formulating a grep pattern to find examples that > doesn't produce a lot of noise. > > These are "0 is no limit": > > pack.windowMemory > pack.deltaCacheSize > git-daemon --max-connections > > These are "-1 is no limit": > > git-grep --max-depth > rev-list --max-parents (I think?)
I am unsure if "limiting to the top-level" is depth 0 or depth 1, but if it is depth 0, --max-depth=0 that does not recurse is sensible and cannot be used as a signal for "unlimited".
Same for --max-parents=0 that would be a legit way to ask for "root commits only".
I do not think the system fundamentally would not work with 0 bytes of window memory or 0 connections, so "0 is unlimited" for them sounds appropriate. I would not be surprised if the reason why "0 is unlimited" fields did not choose to use "-1" as the "unlimited" signal was because the internal type for these fields is unsigned.