Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 <[email protected]> Change-Id: I8dafa2358d039ad1c07e9a512c1d10fed5845738
- Loading branch information