GitoxideLabs/gitoxide gix-config-value-v0.20.0

gix-config-value v0.20.0

on GitHub

Bug Fixes

• accept git's 12-bit hex color shorthand
  git-config(1) documents two hex forms: "24-bit RGB values as hex, like
  #ff0ab3, or 12-bit RGB values like #f1b, which is equivalent to the 24-bit
  color #ff11bb". Only the 24-bit form was parsed, because the hex branch
  required exactly six digits, so #f1b was rejected as an invalid color.

  Both lengths are now handled, with each shorthand digit doubled to make
  the byte, which is what git does. The expected values in the new test
  were recorded from git config --type=color on git 2.50.1.

• accept 0b integers
  C23 strtoimax() recognizes binary prefixes during base-0 parsing, while older
  platform implementations may not.

  Accept the syntax consistently across platforms for signed and suffixed binary
  values while preserving rejection of signs after the prefix.

Changed (BREAKING)

• migrate errors to gix-error

  Rubber stamp

• raise MSRV to Rust 1.88

  The newly published dua-core 3.3 release used by linked-worktree removal
  requires Rust 1.88, so raise every workspace crate and the advertised badge
  together.

  Keep the MSRV checks buildable by selecting the latest sysinfo and rusqlite
  release lines that support Rust 1.88.

Bug Fixes (BREAKING)

• expand ~ and ~user like git does
  Git expands ~ and ~user paths via interpolate_path() in path.c.
  In gix-config-value, Path::interpolate() previously required a trailing
  slash for the current user (~/) and required a slash for named users
  (self.starts_with(b"~") && self.contains(&b'/')). Consequently:

  • A standalone ~ was left unexpanded as a literal "~".
  • A standalone ~user without a trailing slash was left unexpanded as a literal "~user".
  • A nonexistent user without a slash (~nonexistent) silently returned the literal instead of producing a user lookup error.

  Recorded from git -c t.k=<input> config --type=path t.k on git 2.50.1:

  input	git	before	after
  ~	/home/user	"~"	/home/user
  ~/	/home/user/	/home/user	/home/user
  ~/foo	/home/user/foo	/home/user/foo	/home/user/foo
  ~user	/home/user	"~user"	/home/user
  ~user/	/home/user/	/home/user	/home/user
  ~user/foo	/home/user/foo	/home/user/foo	/home/user/foo
  ~nonexistent	error	"~nonexistent"	error

• parse a boolean's number like git does
  git_parse_maybe_bool_text() hands the numeric fallback to
  git_parse_int(), so it takes the same bases and k/m/g suffixes as
  an integer and is bounded to a C int. This used a plain decimal
  i64::from_str, so 0x0, 1k and -0x10 were refused while 08 and
  values past INT_MAX were accepted.

  Routed through Integer, which already matches git since #2967.
  Expectations recorded from git config --type=bool on git 2.50.1.

• parse integer bases the way git does
  git hands config integers to strtoimax() with a base of 0, so a 0x
  prefix means hexadecimal and a leading 0 means octal. Integer::try_from
  used a plain decimal parse, which diverged from the reference implementation
  in two ways:

  value	git config --type=int	gix-config-value before
  0x10	16	error
  0x10k	16384	error
  0X1F	31	error
  -0x10	-16	error
  010	8	10

  The 010 row is the reason for the !: a leading zero produced a different
  number rather than an error, so any config written with a padded or octal
  value was read as decimal without complaint.

  Numbers are now parsed by detecting the sign, then the base, keeping the sign
  attached to the digits so that i64::MIN still parses (its magnitude alone is
  out of range). The suffix path uses the same parser, so 0x10k and 010k
  behave like git.

  Expectations in bases_match_git are the recorded output of
  git config --type=int --get under git 2.50.1, including the values git
  itself rejects: 08, 09, 0x, 0xg, 0b101 and 0o17.

Commit Statistics

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

Commit Details