Austin Seipp ddfdf5e357 cli: allow snapshot.max-new-file-size to be a raw u64 ... Previously, this command would work: jj --config-toml='snapshot.max-new-file-size="1"' st And is equivalent to this: jj --config-toml='snapshot.max-new-file-size="1B"' st But this would not work, despite looking like it should: jj --config-toml='snapshot.max-new-file-size=1' st This is extremely confusing for users. This config value is deserialized via serde; and while the `HumanByteSize` struct allegedly implemented Serde's `visit_u64` method, it was not called by the deserialize visitor. Strangely, adding an `visit_i64` method *did* work, but then requires handling of overflow, etc. This is likely because TOML integers are naturally specified in `i64`. Instead, just don't bother with any of that; implement a `TryFrom<String>` instance for `HumanByteSize` that uses `u64::from_str` to try parsing the string immediately; *then* fall back to `parse_human_byte_size` if that doesn't work. This not only fixes the behavior but, IMO, is much simpler to reason about; we get our `Deserialize` instance for free from the `TryFrom` instance. Finally, this adjusts the test for `max-new-file-size` to now use a raw integer literal, to ensure it doesn't regress. (There are already in-crate tests for parsing the human readable strings.) Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I8dafa2358d039ad1c07e9a512c1d10fed5845738		2024-04-19 13:03:24 -05:00
..
examples
src
testing
tests	cli: allow snapshot.max-new-file-size to be a raw u64	2024-04-19 13:03:24 -05:00
build.rs
Cargo.toml
LICENSE