---
title: Explanation
description: Why rtb-forge is shaped the way it is, with one crate holding two slices, link-time backend registration, a mixed gix/git backend, and what it deliberately does not do.
tags: [explanation]
---
# Explanation
Background and reasoning. Nothing here is needed to use the crate; it is here so
that when the crate behaves in a way you did not expect, you can tell whether
that is a decision or a defect.
| [Why release providers and git operations share one crate](01-two-slices-one-crate.md) | What the two slices are, and why they are not two crates |
| [Why backends register themselves at link time](02-link-time-registration.md) | What `linkme` buys, and what it costs |
| [Why the write paths shell out to git](03-why-write-paths-shell-out.md) | Where the "pure Rust git" claim stops being true |
| [What rtb-forge does not do](04-what-this-does-not-do.md) | The limits, stated as limits |
## Where the design decisions are recorded
The original design records are point-in-time specs on the rust-tool-base
wiki, chiefly [spec 0012](https://gitlab.com/phpboyscout/rust-tool-base/-/wikis/specs/0012-rtb-vcs-v0.1) for the release-provider
slice and [spec 0023](https://gitlab.com/phpboyscout/rust-tool-base/-/wikis/specs/0023-v0.5-scope) for the git operations. They
are not documentation and they are not maintained alongside the code. Where a
spec and this crate disagree, the crate is right.
These pages restate the reasoning in their own words so you do not have to read
a spec to understand the code.