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 fsync_components(&self) -> Option<FsyncComponents>

What: The components core.fsync makes Git flush in this repository; None when the value is one this does not model. Why: Git’s own writes follow core.fsync and the service’s in-process writes follow the same setting. The last entry decides alone and starts from the default (FsyncComponents::default_set); the reading is FsyncComponents::parse. A key written without a value is refused by Git, so it is not modelled.

In TS you’d write (pseudocode):

const value = entries('core.fsync').at(-1); // undefined: the default

pub fn hardens_index(&self) -> Option<bool>

What: Whether core.fsync names the index, so native Git flushes its index writes in this repository; None when the value is one this does not model. Why: The service writes the index in process, so it follows the setting Git’s own index write follows. The components that include the index are index, added and all.

In TS you’d write (pseudocode):

const hardens = fsyncComponents()?.has('index');

pub fn import_fsync_value(&self) -> Option<String>

What: The core.fsync value to give the one git fast-import that imports a landing’s commits, or None when it is to be left as it is. Why: Native Git writes the objects of a commit as loose objects, which its default core.fsync does not flush, while fast-import flushes the temporary pack it writes (and deletes again when the batch is small). A repository that names loose-object (or sets the deprecated core.fsyncObjectFiles) gets its set with the pack and its metadata added when it lacks them, so a pack the import keeps is flushed as the loose objects would be; any other gets the set it has without the packs; a value this does not model is left alone.

In TS you’d write (pseudocode):

set.has('loose-object') || legacyObjectFiles ? undefined : set.without('pack', 'pack-metadata').toValue()

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