Struct ConfigSnapshot 

pub struct ConfigSnapshot { /* private fields */ }

What: The parsed listing of one Git configuration read. Why: It is read once per commit with the caller’s global options, and reused by the consumers that would otherwise each start git config.

In TS you’d write (pseudocode):

type ConfigSnapshot = { entries: ConfigEntry[]; readWithoutGlobalOptions: boolean };

Implementations

impl ConfigSnapshot

pub fn parse(listing: &[u8], without_global_options: bool) -> Option<Self>

What: Parse the bytes of git config --list -z --show-scope. Why: The listing is scope NUL key [LF value] NUL repeated; a listing in any other shape is refused whole, so a half-understood configuration is never used.

In TS you’d write (pseudocode):

parseConfigList(bytes, { withoutGlobalOptions });

pub fn entries(&self) -> &[ConfigEntry]

What: The entries in listing order. Why: Consumers that scan for a family of keys (hook definitions) read them directly.

In TS you’d write (pseudocode):

snapshot.entries

pub fn without_global_options(&self) -> bool

What: Whether the read carried no global options, so a consumer that runs Git without them may reuse it. Why: A -c, -C or --git-dir in front of the read changes what Git lists, and a consumer that ignores the caller’s options must not see their effect.

In TS you’d write (pseudocode):

snapshot.withoutGlobalOptions

pub fn path_value(&self, key: &str) -> Lookup<String>

What: git config --type=path --get <key> for values Git returns unchanged. Why: core.hooksPath is read this way.

In TS you’d write (pseudocode):

snapshot.pathValue('core.hookspath');

pub fn bool_value(&self, key: &str) -> Lookup<bool>

What: git config --type=bool --get <key>. Why: The hook switches are read this way.

In TS you’d write (pseudocode):

snapshot.boolValue('hook.pre-commit.enabled');

pub fn maintenance_records(&self) -> Option<BTreeMap<String, String>>

What: The maintenance keys as git config --type=bool-or-int --null --get-regexp prints them: each set key with the text of its last value. Why: The maintenance decision parses that listing; None when any maintenance entry is not modelled.

In TS you’d write (pseudocode):

snapshot.maintenanceRecords();

pub fn proves_files_ref_storage(&self) -> bool

What: Whether the ref storage is proven to be the files backend. Why: git rev-parse --show-ref-format prints reftable only when extensions.refStorage is set, so a listing without that key, read without global options, proves files; any listing that names the key (in any scope, from any file) is left to Git, which also applies the repository-format rules.

In TS you’d write (pseudocode):

snapshot.withoutGlobalOptions && !snapshot.entries.some((entry) => entry.key === 'extensions.refstorage');

Trait Implementations

impl Clone for ConfigSnapshot

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ConfigSnapshot

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for ConfigSnapshot

impl PartialEq for ConfigSnapshot

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for ConfigSnapshot