GitoxideLabs/gitoxide gix-config-v0.60.0

gix-config v0.60.0

on GitHub

Bug Fixes

• keep standalone comments separate when replacing continued values

  Replacing a continued value that ended at a comment on the next physical line
  removed the continuation newline, turning the standalone comment into an inline
  comment on the replacement value.

  Retain the final continuation newline when an empty ValueDone event is followed
  by a comment. Cover hash and semicolon comments with LF and CRLF, along with
  quoted comment markers that remain value content. This matches git config
  parsing behavior.

• decode the config \b escape to the backspace byte, matching git
  normalize decoded a \b escape in a quoted config value with out.pop(),
  deleting the preceding byte, so "x\bic{}y" normalized to "y" and a
  leading \b was silently dropped.

  git decodes \b to the backspace character (0x08). Push 0x08 to match,
  alongside \n and \t.

• an implicit boolean followed by whitespace is true, like in Git.
  A key without = is an implicit boolean and reads as true, but only if
  nothing at all follows it on the line. A single trailing space or tab turned
  it into false:

  $ printf '[core]\n\tbare \n' > f
  $ git config --file f --bool core.bare
  true                                    # git 2.50.1 (Apple Git-155)
  
  File::boolean("core.bare")  ->  Ok(Some(false))
  File::string("core.bare")   ->  Some("")
  

  Trailing whitespace after a key is easy to produce by hand or with an editor
  that does not strip it, and the mistake reaches porcelain: with
  [core]\n\tfileMode \n in .git/config, Repository::filesystem_options()
  reports executable_bit: false, so gix stops honouring the executable bit
  on a repository where Git still honours it.

  key_and_value_range_by_in() decided implicit-vs-explicit by looking at
  whether the value event sits directly behind the value name. The parser emits
  a Whitespace event between SectionValueName and the synthetic empty
  Value when the key has trailing spaces or tabs, which pushed the value one
  slot further and made the pair look explicit. Decide on the presence of a
  KeyValueSeparator between name and value instead, which is what the
  distinction is actually about.

  Explicit values are unaffected: bare =, bare = and bare="" still read
  as false with an empty string value, matching Git. Lines that Git accepts
  only gain the classification Git gives them; lines Git rejects as bad config
  (a key followed by a bare word or a comment, with no =) also become
  implicit, which is a change but not one Git constrains — see the PR
  description.

• keep the value when a line continuation is followed by an empty line
  A value ending in a continuation backslash was parsed as the empty string
  when the continuation line turned out to be empty, discarding everything
  accumulated before the backslash. With [core]\n\tk = abc\ as the file
  content plus the bytes below, git config --file f core.k prints abc
  in every case:

  bytes after the continuation backslash	git	gix-config
  \n\n (empty line)	abc	`` (empty)
  \n; comment	abc	`` (empty)
  \n then EOF	abc	`` (empty)
  \n\n[other]\n	abc	`` (empty)
  \r\n then EOF	abc	`` (empty)
  EOF, no trailing newline	abc	abc
  \n \n (blank line with spaces)	abc	abc

  value() emits one ValueNotDone per continued chunk and terminates the
  sequence with ValueDone, which is what every consumer concatenates. When
  the final chunk was empty it took the empty-value shortcut and dispatched a
  bare Event::Value instead, and a bare Value reads as a complete value,
  so the preceding ValueNotDone chunks were dropped. That also broke the
  invariant documented on Event::ValueNotDone, that ValueDone follows it.

  The shortcut now dispatches ValueDone when a continuation was seen and
  Value otherwise, matching the distinction the non-empty path already
  makes. Values without a continuation are unaffected, as are continuation
  lines holding only whitespace - those never reached the shortcut, because
  the whitespace is trimmed after the branch rather than before it.

  Rows 1, 2 and 4 are a regression from 91c854e (fix!: remove winnow and replace it with hand-implemented parsers everywhere), which first shipped
  in gix-config 0.56.0. Verified by building f267626, whose gix-config/src
  tree (b2fda5bc7) is identical to the one tagged gix-config-v0.55.0, so that
  measurement is of released 0.55.0 and 0.55.0 is demonstrably the last
  release with the correct behaviour. It is also the last building ancestor:
  the immediate parent b060eb2 does not build in isolation, as gix-object
  fails against the changed gix-actor API until its "adapt to changes"
  follow-up. Rows 3 and 5 were already wrong at f267626, so those two are
  long-standing rather than regressed. Row 6 was a parse error before the
  rewrite, fixed by 5127973.

• normalize expanded git-dir paths on Windows during include matching.

  Git matches includeIf.gitdir conditions against forward-slash paths on
  Windows. Relative git-dir contexts in gix-config were initially normalized,
  but their realpath-expanded fallback retained native backslashes and failed to
  match forward-slash conditions. Normalize that fallback as Git does and make
  the environment test use the matching form explicitly.

Commit Statistics

• 19 commits contributed to the release over the course of 30 calendar days.
• 30 days passed between releases.
• 5 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details