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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux