A config key written without a value is dropped, where git reads it as true #2237

GitConfigParser cannot read a key that appears with no =, which is valid git config and means true.

[flag]
	enabled

git config -f cfg --get flag.enabled              -> exit 0, empty output
git config -f cfg --type=bool --get flag.enabled  -> true
git config -f cfg --list                          -> flag.enabled

>>> GitConfigParser("cfg", read_only=True).get_value("flag", "enabled")
NoOptionError

The key is not stored at all. OPTCRE requires [:=], so the line does not match, and the branch at git/config.py:589-594 swallows it:

else:
    # Check if it's an option with no value - it's just ignored by git.
    if not self.OPTVALUEONLY.match(line):

The comment is the part I would fix first regardless of the rest: git does not ignore it. --list shows the key and --type=bool reads it as true. OPTVALUEONLY exists only to recognise these lines so they can be discarded without raising a ParsingError.

One constraint on any fix, which is why I am asking rather than sending a patch. git distinguishes a valueless key from an empty one, and they differ exactly where it matters:

[f]
	novalue        --get ''   --type=bool true
	empty =        --get ''   --type=bool false

So storing "" for the valueless case would make it read as false, the opposite of git. Representing it needs something that get_value can render as "" while the boolean path reads as true.

There is also a write-back question: such a key is currently dropped on a read-modify-write, and once it parses it would need to be written back without an =.

Happy to send the patch with tests if you tell me which representation you want; the write-back ripple is the reason I have not guessed.

Found with git 2.50.1 and GitPython at a9913c7.

Assisted-by: Claude Opus 5 (Claude Code), per the identification rule in CONTRIBUTING.md.