From: Patrick Steinhardt <ps@pks.im>
Date: Tue, 14 May 2024 04:54:39 GMT
Subject: Re: [PATCH v2 10/11] reftable: make the compaction factor configurable
Message-ID: <ZkLujyOtvKBf2LOM@tanuki>
In-Reply-To: <xmqqmsotheb5.fsf@gitster.g>

On Mon, May 13, 2024 at 09:22:38AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > So this may be good enough for now, and when we gain the ability to
> > parse floats we may convert this to accept floats, as well. An
> > alternative would be to convert this to percent, where the default value
> > would be 200. That should give sufficient flexibility without having to
> > introduce floats.
> 
> There already is an established way to specify float with arbitrary
> precision on the command line if we limit the value to 0..1, by the
> way.
> 
> https://lore.kernel.org/git/Pine.LNX.4.58.0505191516350.2322@ppc970.osdl.org/

The problem is that we don't want to limit the value to 0..1, but to
1..n. 1 really is the lowest semi-sensible number you can pick and means
that all tables should have the same size. And in practice, there is no
upper limit, even though it's probably not all that reasonable to pick
anything beyond 10.

In any case, I'd propose to keep this as-is for now. The simple reason
is that we have preexisting commands (`git repack -g`) and in-flight
series (pseudo-merge bitmaps) that also use plain integers to represent
the geometric factor. So I'm aiming for consistency. From thereon we can
then iterate and design a solution that works for all of them, e.g. by
allowing for floats outside of the 0..1 range in whatever form.

> It is amusing to revisit an ancient discussion thread.  I can see,
> on the same thread in the discussion following that message, that
> back in May 2005, we were discussing "intent to add" that did not
> get invented until mid 2008 already ;-).

:)

Patrick