Found in a real deployment (mbator.pl blog pipeline): rad lfs init configures a client-side fetch refspec for refs/notes/rad-lfs, but git-remote-rad's for_fetch() never advertised any such ref -- notes only exist per-peer, under refs/namespaces/<peer>/refs/notes/rad-lfs, with no canonicalization step the way refs/heads/refs/tags get one. Requesting an unadvertised refspec fails the *entire* git fetch, not just that one ref, so any repo with `rad lfs init` run could no longer git fetch/pull at all, LFS or not. Fix: expose each peer's refs/notes/rad-lfs individually, as refs/notes/rad-lfs/<peer-id> (list.rs's for_fetch), matching how patch refs already work rather than trying to canonicalize -- notes are per-peer contributions (any peer can commit an LFS-tracked file, not just delegates), so unlike heads there's no single "correct" value to resolve to; canonicalizing would silently drop non-delegate contributors' objects. rad lfs init's fetch refspec becomes a wildcard (+refs/notes/rad-lfs/*:refs/notes/rad-lfs/*); push is unchanged (already worked -- for_push() turns out to be purely informational for git's list-for-push handshake, not an enforcement gate, so the actual send-pack call was never restricted to heads/tags despite what for_push() lists). rad lfs store/fetch/rekey and seed/unseed's pinning (ipfs.rs::lfs_cids) now read across every notes ref instead of assuming one canonical ref, merging recipient lists for notes that share a CID (e.g. after a rekey performed by a different peer than the original committer) while keeping genuinely different ciphertexts (from two peers independently encrypting byte-identical content) as separate candidates to try in turn. Also added a migration step so re-running `rad lfs init` on an already-configured repo actually fixes it, by removing the old non-wildcard fetch refspec rather than just adding the wildcard alongside a still-broken entry. Verified through the real git-remote-rad transport (not the storage-copy shortcut used for earlier testing, since this bug lives specifically in that transport): fresh identities, a real rad:// remote matching exactly what `rad init` configures, a genuine `git fetch rad` that used to fail with "fatal: couldn't find remote ref refs/notes/rad-lfs" now succeeds and pulls the notes ref, and `git lfs pull` afterward correctly decrypts private content end-to-end (SHA-256 verified). Re-verified the rekey flow through the same real path too. |
||
|---|---|---|
| .cargo | ||
| .config | ||
| .github | ||
| .radicle | ||
| build | ||
| crates | ||
| debian | ||
| radicle-lfs-transfer@d67ac79f40 | ||
| scripts | ||
| simulation | ||
| systemd | ||
| windows | ||
| .codespellrc | ||
| .dockerignore | ||
| .env.seed | ||
| .envrc.sample | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitmodules | ||
| .gitsigners | ||
| .rustfmt.toml | ||
| .typos.toml | ||
| ARCHITECTURE.md | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| DCO | ||
| HACKING.md | ||
| LFS-IPFS.md | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| NOTES-lfs-notes-fetch-bug.md | ||
| README.md | ||
| RELEASE.md | ||
| VERSIONING.md | ||
| build.rs | ||
| clippy.toml | ||
| deny.toml | ||
| flake.lock | ||
| flake.nix | ||
| git-remote-rad.1.adoc | ||
| justfile | ||
| rad-id.1.adoc | ||
| rad-patch.1.adoc | ||
| rad.1.adoc | ||
| radicle-node.1.adoc | ||
| rust-toolchain.toml | ||
README.md
❤️🪵
Fork: Git LFS support, backed by IPFS
This is a fork of upstream
radicle-dev/heartwoodadding Git LFS (large file) support, with large file content stored on each contributor's own local IPFS node rather than a central server. Everything below the horizontal rule is upstream's own README, unchanged. SeeLFS-IPFS.mdfor the full design, troubleshooting, and background — this section is just the quick start.The LFS byte-transfer logic lives in a separate, small companion repository: radicle-lfs-transfer, included here as a git submodule.
Dependencies (Arch Linux)
# To build and install rad/radicle-node/radicle-lfs-transfer sudo pacman -S --needed rust git openssh base-devel # To actually use Git LFS (not needed to build/install anything) sudo pacman -S --needed git-lfs kuboOn other distributions: a Rust toolchain (e.g. via rustup), Git, OpenSSH, a C toolchain — and, only for using
rad lfs, Git LFS and Kubo.Zero to usable
# Clone with the submodule git clone --branch rad-lfs-ipfs --recurse-submodules \ ssh://git@git.hswro.org:9022/mab122/radicle-heartwood-lfs.git cd radicle-heartwood-lfs # Build & install rad, radicle-node, git-remote-rad, and rad-lfs-transfer to one place cargo install --path crates/radicle-cli --force --locked --root ~/.radicle cargo install --path crates/radicle-node --force --locked --root ~/.radicle cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle cargo install --path radicle-lfs-transfer --force --locked --root ~/.radicle # Add the install root to your PATH (e.g. in ~/.bashrc / ~/.zshrc) export PATH="$HOME/.radicle/bin:$PATH" # Verify rad --versionFrom here, use
radexactly as upstream describes below (rad auth,rad init, etc). The only new commands arerad lfs init(run once per repository you want large-file support in) andrad lfs rekey(run after granting a new collaborator access to a private repository, so they can decrypt previously-committed LFS objects too) — seeLFS-IPFS.mdfor that workflow and how private-repo content gets encrypted before it reaches IPFS. Nothing above requires IPFS; Git LFS support specifically needs a runningipfs daemon, andrad lfs initwill tell you plainly if one isn't reachable rather than failing confusingly later.
Radicle Heartwood Protocol & Stack
Heartwood is the third iteration of the Radicle Protocol, a powerful
peer-to-peer code collaboration and publishing stack. The repository contains a
full implementation of Heartwood, complete with a user-friendly command-line
interface (rad) and network daemon (radicle-node).
Radicle was designed to be a secure, decentralized and powerful alternative to code forges such as GitHub and GitLab that preserves user sovereignty and freedom.
See the Radicle home page for general information, and the Zulip chat to talk to the project.
See the Protocol Guide for an in-depth description of how Radicle works.
Installation
Requirements
- Linux or Unix based operating system.
- Git 2.34 or later
- OpenSSH 9.1 or later with
ssh-agent
📀 From binaries
Requires
curlandtar.
Run the following command to install the latest binary release:
curl -sSf https://radicle.dev/install | sh
Or visit our download page.
📦 From source
Requires the Rust toolchain.
You can install the Radicle stack from source, by running the following commands from inside this repository:
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
Or directly from our seed node:
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
Running
Systemd unit files are provided for the node under the /systemd folder.
They can be used as a starting point for further customization.
For running in debug mode, see HACKING.md.
Feedback
If you have feedback, feel free to create issues using rad issue, join
our Zulip, or email feedback@radicle.dev.
Emails sent to this address are automatically posted to
our public #feedback channel on Zulip, revealing the
From header (which usually contains your name and email
address). This allows us to discuss your feedback on Zulip, and, if necessary,
respond to you via email.
Contributing
See CONTRIBUTING.md and HACKING.md for an introduction to contributing to Radicle.
License
Radicle is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.