This uses `zlib-rs`, a native Rust library that is comparable in
performance to `zlib-ng`. Since there’s no complicated C build
and gitoxide only has one hashing backend now, this lets us drop our
`packaging` feature without adding any awkward build requirements.
`zlib-rs` is generally faster at decompression than
`zlib-ng`, and faster at compression on levels 6 and 9; see
<https://trifectatech.org/blog/zlib-rs-is-faster-than-c/>
for details.
I couldn’t get reliable‐looking benchmark results out of my
temperamental laptop; `hyperfine` seemed to think that some random
`jj` workloads I tested might be slightly slower than with `zlib-ng`,
but it wasn’t unambiguously distinguishable from noise, so I’d
like to see measurements from others.
It’s certainly a lot faster than the previous default, and I
think it’s likely that `zlib-rs` will continue to get faster
and that it’s more than worth avoiding the headaches of a native
library with a CMake build dependency. (Though on the other hand,
if distributions move in the direction of shipping `zlib-ng` by
default, maybe there will be more motivation to make `libz-ng-sys`
support system libraries.)
This should fix git::import_refs() issue with gix 0.71.0. Old commits could be
repopulated by importing stale refs stored in packed-refs.
https://github.com/GitoxideLabs/gitoxide/issues/1928
The Zlib license is added to the allow list because foldhash appears in the
dependency chain.
The paste crate hasn't had a maintainer since Oct. 2024. We don't use it
directly, but it's used by ratatui, and there's no direct replacement for it
AFAIK.
Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
This is currently blocking PRs because ci fails:
```
error[unmaintained]: paste - no longer maintained
┌─ /github/workspace/Cargo.lock:262:1
│
262 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
│
├ ID: RUSTSEC-2024-0436
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md)
that this project is not longer maintained as well as archived the repository
├ Announcement: https://github.com/dtolnay/paste
├ Solution: No safe upgrade is available!
├ paste v1.0.15
└── ratatui v0.29.0
└── scm-record v0.5.0
└── jj-cli v0.27.0
└── (dev) jj-cli v0.27.0 (*)
advisories FAILED
```
The WTFPL license is added to the allow list. I've never heard about this
license, but it's basically the same as public domain according to wikipedia.
This is needed because old keys are becoming unsupported in the next
version of the `cargo-deny` action.
This was obtained as follows:
- Run `cargo deny init`
- Modify (only) the `licenses.allow` field to match what we had before.
The `atty` crate seems unmaintained. There's
https://rustsec.org/advisories/RUSTSEC-2021-0145 filed against it,
which `cargo-deny` complains about. A fix for that has been open for
well over a year without being fixed
(https://github.com/softprops/atty/pull/51). It turns out the
functionality is also available via the `crossterm` crate (thanks,
@yuja), which we already depend on.
Since we also depend on `atty` via `clap`, I also added an exception
to the `cargo-deny` config.
Our current version of `cpufeatures` was yanked so we needed to
upgrade at least that. Note that I had to add "UNICODE-DFS-2016" as an
allowed license for `cargo-deny`. I also had to upgrade `chrono` from
0.4.20 to 0.4.22 in the `Cargo.toml` files to prevent `cargo update`
from *downgrading* it in the lock file.
