On Mon, May 13, 2024 at 09:22:38AM -0700, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> 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@xxxxxxxxxxxxxxx/ 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
Attachment:
signature.asc
Description: PGP signature
