Gitility.Snapshot (Gitility v0.2.0)

An immutable view of one commit — the unit every semantic query takes.

Creating a snapshot peels and validates the commit once and records its commit and root tree IDs. From then on the snapshot cannot change: branches may move, refs may vanish, and every query against this snapshot still answers about exactly this commit. commit_oid is the stable citation for "what code is this answer about".

A snapshot needs only an ODB — refs are for resolving names, and by the time a snapshot exists the name is resolved. See Gitility.Repository.snapshot/3 for selector-based creation.

Summary

Types

t()

A pinned snapshot: the store it reads from plus its identity.

Functions

open(odb, commit_oid, opts \\ [])

Opens a snapshot directly from an ODB and a commit ID.

Types

t()

@type t() :: %Gitility.Snapshot{
  commit_oid: Gitility.OID.t(),
  odb: Gitility.ODB.t(),
  tree_oid: Gitility.OID.t()
}

A pinned snapshot: the store it reads from plus its identity.

Functions

open(odb, commit_oid, opts \\ [])

@spec open(Gitility.ODB.t(), Gitility.OID.t() | String.t(), keyword()) ::
  {:ok, t()} | {:error, Gitility.Error.t()}

Opens a snapshot directly from an ODB and a commit ID.

The commit is read and validated (:not_a_commit for other object types; annotated tags are peeled to their commit). Opening a SHA-256 snapshot returns {:error, %Gitility.Error{code: :unsupported_hash}} until engine support lands — a clean refusal, never a wrong answer.