pub fn get(config: &File, key: &str) -> Option<String>Expand description
Reads a dotted key, if present.
A key written with no value at all — [core]\n\tautocrlf — is true to git,
but has no raw value to return, so it comes back as Some("true"): git’s own
reading of that line, spelled the way every caller already tests for.
Some("true") rather than Some(""), and the difference is a security
one. gix-config reports key (no =) and key = (an empty value)
identically — the first as Err(KeyMissing) from raw_value, the second as
Ok("") — and git does not: measured on git 2.55, git config --type=bool
reads the first as true and the second as false. Flattening both to
the empty string and calling that true made filter.git-xcrypt.required =
read as enabled, while git ignored the failing filter and stored the
plaintext with git add exiting 0 — and status, the gate that exists to
catch exactly that, reported no gap.
A key gix-config will not parse gives None rather than a panic. Its
raw_value takes the key through AsKey::as_key, which panics on anything
it cannot split — notdotted is enough. No caller passes such a key today,
and the -c reader filters them out before they get here, so this is not a
fix for a live bug; it is a fix for the shape of one. get is on the
filter path, and with required = true a panic there does not fail one
command, it aborts every git operation in the repository until someone
unregisters the driver by hand. A lookup that cannot name a section has no
answer, and saying so is the same thing this function already does two lines
further down for the same key.