[suggestion] support non-negative float number in git-repack --max-pack-size

Hi,

I would like to create packfiles with charm-numbered size (that is for 
example use 49.99M instead of 50M) with git-repack:

$ git repack --max-pack-size=49.99M -a -d

But Git didn't support it:

error: option `max-pack-size' expects a non-negative integer value with an optional k/m/g suffix

The workaround was scaling down to kibibytes:

$ git repack --max-pack-size=52418K -a -d

But the workaround is a rather convoluted to me, because I must convert 
mebibytes (MiB) to kibibytes (KiB). I had to multiply the desired 
packfile size by 1024, as opposed to by 1000 in familiar size notation 
(kilobytes [KB] and megabytes [MB]).

It would be nice if non-negative floating-point number can be allowed in 
--max-pack-size option, so that many users don't have to scale down size 
notation like above.

PS: charm numbers are most often used in pricing, because it's almost 
used everywhere (part of psychological pricing).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

On Mon, Jun 07, 2021 at 01:42:47PM +0700, Bagas Sanjaya wrote:

I would like to create packfiles with charm-numbered size (that is for
example use 49.99M instead of 50M) with git-repack:

$ git repack --max-pack-size=49.99M -a -d

The parser for numbers with units is shared by many options and config
variables. In general, I'm not really opposed to allowing floating point
values which get rounded to the nearest byte for any of them. So no
objection for the general feature if somebody wants to implement it.

But I would note that --max-pack-size is almost never a good idea in
general. I don't know what you think it's accomplishing, but it is
probably making your repository larger than it needs to be, as well as
less performant.

-Peff

ping