mab122
/
radicle-heartwood-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2,970 Commits 2 Branches 0 Tags 10 MiB
Commit Graph

11 Commits

Author SHA1 Message Date
Lorenz Leutgeb 8bac24d6ab
rust/edition/fmt: 2021 → 2024 
Reformat code with `rustfmt`, now that the edition changed from
Rust 2021 to Rust 2024.
 2026-03-30 16:57:51 +02:00
Fintan Halpenny 7862e108b6 Update gix-* crates 
Fixes [CVE-2026-0810].

The `gix` crates require updating due to the security vulnerability above.
They require updating together in lock-step so both `radicle-fetch`
and `radicle-oid` are affected.

`radicle-oid` handles the non-exhaustive nature of `ObjectId`.

`radicle-fetch` updates to the new API types, however, this comes with
some updates to the `ls_refs` protocol.

A regression is documented in [gitoxide issue 2429].
The regression highlighted that it is the duty of the caller to also
filter the outcome of ls-refs, and `ref-prefix` is simply an
optimisation.

The ls-refs code is refactored to better represent and handle this operation.

[CVE-2026-0810]: https://www.cve.org/CVERecord?id=CVE-2026-0810
[gitoxide issue 2429]: https://github.com/GitoxideLabs/gitoxide/issues/2429
 2026-02-16 17:13:39 +00:00
Fintan Halpenny 391571178e fetch: introduce domain type RefPrefix 
Better represent the domain by introducing the `RefPrefix` type.
It captures the different `ref-prefix` values that can be used in the
`ls-refs` step of the protocol.

These are turned into their equivalent `ref-prefix` values using
`RefPrefix::into_bstring`.

This better connects the `ProtocolStage::ls_refs` method with the
`ls_refs::run` through the use of the `RefPrefix` type, rather than
any set of `BString` values.
 2026-02-16 17:11:32 +00:00
Fintan Halpenny 9236277abf fetch: remove `target: "fetch"` 
Going forward, there will be a preference to not use the `target` in
logging, and allow the default of the crate and module to be used
instead.
 2026-01-19 17:56:56 +01:00
Fintan Halpenny e3cb36d950 fetch: clean up logging 
Evaluate the use of `warn!` and `error!` logging in `radicle-fetch`.

The majority are downgraded to `debug!`, the rest either being
downgraded to `info!` or removed altogether.
 2026-01-19 17:56:56 +01:00
Fintan Halpenny 3168107df9 fetch: surface underlying I/O error 
The message that is returned by `gix-transport` for I/O errors can be
unhelpful, since it does not provide the reason for what happened.

Instead, surface the error so that it provides more detail for logging.
 2026-01-05 18:29:52 +01:00
Lorenz Leutgeb b7cfcfff75
workspace: A Little Less `git2` 
Make `git2` an *optional* dependency of `radicle-cob`, and refactor
`radicle` to depend on crates that in turn do not depend on `git2`
*non-optionally*

The main offending dependency of `radicle-cob` is `radicle-git-ext`
from the `radicle-git` workspace in repository
(rad:z6cFWeWpnZNHh9rUW8phgA3b5yGt) which *non-optionally* depends on
`git2`.

So, to achieve removal of this dependency:

 1. The crate is refactored to depend on the new crates
    `radicle-git-ref-format` `radicle-git-metadata`, and
    `radicle-oid` introduced in the previous commits, instead of
    `radicle-git-ext`.
 2. Some code from the `radicle-git-ext` crate in the `radicle-git`
    workspace in repository (rad:z6cFWeWpnZNHh9rUW8phgA3b5yGt) is
    copied. See `crates/radicle-cob/src/backend/git/commit.rs`.

This cascades to `radicle` and its dependents.

  Firstly, the there is an
`impl Deref<Target=git2::Oid> for radicle_git_ext::Oid`. This made
it very convenient to just deref to obtain the wrapped `git2::Oid`,
so there are many expressions of the shape `*oid` in `radicle` and
its dependents. However `radicle-oid` does not provide
`impl Deref<Target=git2::Oid> for radicle_oid::Oid`, as notably,
`Target` is an associated type, and not a type parameter, so an
implementation of `Deref` would tie the new `Oid` too tightly to a
particular implementation.
Instead, work with `impl From<radicle_oid::Oid> for git2::Oid`
(which can be enabled using the feature flag `radicle-oid/git2`).
This explains the changes from `*oid` to `oid.into()` at every
transition to "`git2` land".

  Secondly, `radicle` and its dependents are refactored to also depend
on `radicle-git-ref-format` and (much less prominently)
`radicle-git-metadata` instead of `radicle-git-ext`
This is to avoid pulling in `git2` via these dependencies.

  Thirdly, as the re-exports in `crates/radicle/src/git.rs` change,
they are at the same time also cleaned up. Notably, the types from
`radicle-git-ref-format` are re-exported under `fmt` only, not "twice".

While overall this obviously is very much a breaking change, these
changes should mostly amount to changing from `Deref` to `Into`, i.e.,
`*oid` → `oid.into()` and rewriting imports for `radicle::git::fmt`.
This is indicated by the mostly mechanical nature of the changes to
`crates/radicle-{cli,node,remote-helper}`.
 2025-10-13 16:14:23 +02:00
Lorenz Leutgeb 31039bbceb radicle-fetch: More fine-grained errors 
The `fn io_other` disguises all sorts of errors as I/O errors, making
errors in the transport component of `radicle-fetch` harder to
understand.

Instead, expose a new error type that allows to discriminate.
 2025-08-22 14:56:03 +02:00
Lorenz Leutgeb d2517c5004 radicle-fetch: Fallback to known version 
There's a good chance that gix can just keep going in this case.
 2025-08-22 14:55:19 +02:00
Lorenz Leutgeb 9068033789 chore: Automated fixes generated by clippy 2025-07-25 11:25:05 +02:00
Lorenz Leutgeb 5bc2dc677b repo: Move workspace crates into `crates` subdirectory 
This keeps the top level of the repo cleaner, e.g.
<https://github.com/radicle-dev/heartwood> scrolls less and
<https://app.radicle.xyz/nodes/rosa.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/>
might show more files at the top level.

This way we also don't have to explicitly name all crates in
`Cargo.toml`.
 2025-06-09 15:09:21 +02:00
Renamed from radicle-fetch/src/transport.rs (Browse further)