Bump bytesize from major version 1 to 2

[EliahKagan]

This upgrades the bytesize dependency in Cargo.toml from version 1.0.1 (which was usually selecting 1.3.3) to 2.0.1 (which is the latest version).

There were some nontrivial API changes from major version 1 to 2. Accordingly, this adapts Bytes::format_bytes() to the API change.

The old bytesize::to_string() function was confusing in its second parameter si_prefix: bool, which is why it was removed. But it looks like a value of false, as we were passing, actually caused decimal SI units (rather than binary IEC units) to be used. It's not obvious which units prodash intended to use bytesize to convert to and display in. But this seems to be a minimal change to adapt to the new major version.

In spite of the name si_prefix for the old parameter, experiments show that setting it to true caused values to be converted to and presented in binary IEC units.

Although this attempts not to change which actual units are used, it does produce observable differences for some of them, in how they are presented. In particular, a decimal SI kilobyte is least ambiguously abbreviated "kB" (because "k" is an SI unit symbol prefix for "kilo" in its meaning of 1000), but it was previously written as "KB". It is now expected to be writen as "kB". Tests catch this distinction, and are updated here accordingly to assert that the generally preferable "kB" symbol for decimal SI kilobyte is used.

See also: GitoxideLabs/gitoxide#1947 (comment)

---

A few ways this might not be ready:

• As noted, I'm not sure what the actual intended behavior is here in terms of whether the units should be the decimal SI units or binary IEC units. My preference for units that are based in counts of bytes is, in most applications, to use binary IEC units--but that does not mean it's what people expect here, and it's a bigger change from what was done before so I did not change to that here, instead using the decimal SI units.
• There's a behavioral change here, which required a change to the tests--writing "kB" instead of "KB"--so it seems like maybe this should be a conventional commit, but I haven't made it one, not being sure what is expected here.
• It might be good to try this out in a real-world application, such as by building gitoxide against prodash with these changes and observing what gix clone on a medium-to-large repository looks like.

[Byron]

Thanks a lot, much appreciated.

I don't think I ever much cared about subtleties in how byte-counts are presented, so let's go with this and remove bytesize from the dependency tree of gitoxide.

[EliahKagan]

I don't think I ever much cared about subtleties in how byte-counts are presented, so let's go with this and remove bytesize from the dependency tree of gitoxide.

Can you elaborate? Since all versions of prodash depend on some version of bytesize, and gitoxide uses prodash, presumably bytesize would have to remain somewhere in the dependency tree of gitoxide.

It occurs to me that you may mean that gitoxide should only ever depend on bytesize through prodash. But I don't think prodash exposes all of it, does it? In any case, gitoxide-core uses bytesize directly in at least one place: to produce statistics for gix free pack verify. Since this isn't related to the functionality of prodash, it seems to me that it remains defensible to have that separate dependency.

Alternatively, do you mean simply that we should remove the old, major-version-1 of bytesize from the dependency tree of gitoxide? That should certainly be feasible, I think.

[Byron]

Sorry, I meant bytesize@1 was supposed to be removed from the dependency tree - right now prodash is the reason both versions are pulled in.

[EliahKagan]

No problem, and thanks for clarifying!

[EliahKagan]

I'll open a PR in gitoxide to update prodash, or cause Dependabot to open one (the cadence is monthly, but it can be manually triggered at any time).

[EliahKagan]

I've upgraded prodash in GitoxideLabs/gitoxide#1953.