Crate facett_git 

facett-git — a facett Facet that shows a git repository: its branches, the commit log, the file tree, and syntax-coloured source — all clickable. A consumer (e.g. nornir’s viz) drops it into a FacetDeck to surface git for any repo.

• The repository data is a pure RepoSnapshot (branches / commits / tree). With the gix feature it is read live from disk via RepoSnapshot::open; without it the host supplies a snapshot (and a blob), so the facet builds and tests with no git dependency.
• Source is rendered with a deterministic Rust [highlight]er into an egui LayoutJob (egui can render coloured Rust text — this is how).
• Everything observable (selected branch, open path, counts) is in state_json (LAW 6 / FC-6), so it is headless-testable.

FC contract (the canonical Elm split, FC-2 / FC-9)

• GitState — the complete observable, serializable, round-trippable state (the repo snapshot, the open blob, the selected branch / path, the visible pane, the zoom). GitView::state hands back a &GitState.
• Msg + GitView::update — the single mutation path (FC-2): the same gestures the canvas clicks drive (pick a branch, open a tree path, switch pane, zoom, load a blob), so a headless driver (facett_core::harness) reaches them.
• GitView::view — a pure paint (FC-9): it reads &self, paints the three columns, and returns the Msgs the interactions produced; the impl_facet_via_elm! bridge applies them.
• Rich state_json — the derived counts (branches / commits / tree_entries), the head branch, and the flattened selection a driver reads are derived from the snapshot, not a plain serde(state()), so the macro is invoked in form 3 (custom_state_json) to publish those keys.

Re-exports

pub use highlight::highlight;

pub use highlight::Kind;

pub use highlight::Span;

pub use model::Blob;

pub use model::Branch;

pub use model::CommitRow;

pub use model::RepoSnapshot;

pub use model::TreeEntry;

Modules

highlight

Deterministic Rust source syntax highlighter → coloured spans an egui LayoutJob can render. Pure (no egui, no I/O), so it is unit-tested without a window and produces bit-identical spans for the same input (FC-7). A tiny hand-written tokenizer — not a full parser — classifying the things that matter for reading code: keywords, types, strings/chars, line+block comments, numbers, attributes, and punctuation.

model

Pure git snapshot model — the data a crate::GitView renders: branches, the commit log, and a directory listing of the tree. The data types are always available + serializable (so the facet builds, tests, and state_jsons with no git dependency); the live reader [RepoSnapshot::open] is gated behind the gix feature.

Structs

GitState

The complete observable state (FC-1 / FC-3) of a GitView, in one serializable, round-trippable struct: the repo snapshot, the open source blob, the selected branch / path (keyed on stable names, FC-5), the visible pane, and the source zoom. GitView::state hands back a &GitState; a headless driver (facett_core::harness) snapshots it after feeding a Vec<Msg>.

GitView

The git repository facet.

Theme

Colours for each syntax Kind. Default is a dark theme.

Enums

Effect

Side work as data (FC-8). The git browser does no I/O — every Msg mutates only the in-memory GitState — so this is uninhabited on purpose: the type-checked statement that GitView::update never asks the host to do anything. (Live repo reads happen up-front in [RepoSnapshot::open], not here.)

Msg

A robot-/CLI-addressable control message (FC-2) — the named boundary a headless driver (or a host) drives the git browser through, the same effect the canvas clicks produce. Applied by GitView::update; it is the only mutation path.

Pane

Which middle-pane view is showing. Part of the observable GitState, so it is serializable; the string form the deck reads ("tree" / "log") is emitted by [GitView::state_json].