GitoxideLabs/gitoxide gix-revision-v0.49.0

gix-revision v0.49.0

on GitHub

Bug Fixes

• resolve the empty pattern in <rev>^{/} like Git, instead of skipping it.
  The parser dropped the find() delegate call whenever the pattern in
  <rev>^{/<pattern>} was empty, turning the whole navigation step into a
  no-op on the grounds that an empty pattern matches everything.

  That reasoning only holds for a commit anchor and a non-negated pattern.
  Git routes <rev>^{/...} through GET_OID_COMMITTISH and searches from
  the peeled commit even when the pattern is empty - object-name.c notes
  "$commit^{/}. Some regex implementation may reject empty regex, but this
  is safe". Thus git rev-parse 'b-tag^{/}' yields the commit the
  annotated tag points at, while gix returned the tag object itself. A
  negated empty pattern matches no commit at all, so Git fails HEAD^{/!-}
  while gix silently succeeded with HEAD.

  Now the parser always forwards the pattern to Navigate::find(), whose
  implementation in gix already handles the empty case correctly on both
  the revparse-regex and the substring fallback paths: it peels the
  anchor to a commit first and treats an empty pattern as match-all, which
  fails naturally when negated. The delegate behind gix revision explain
  makes no assumption about patterns and needs no change.

  The make_rev_spec_parse_repos fixture gains baselines for @^{/},
  @^{/!-} and b-tag^{/}; its archive needs regeneration.

Other

• delegate zero ancestor traversal ~0 is a no-op only after resolving its anchor to a commit. The parser cannot
  know whether the anchor is an annotated tag, and suppressing NthAncestor(0)
  prevents higher-level delegates from peeling it as Git does. Always forward zero
  so each Navigate implementation can apply its own object semantics.

Changed (BREAKING)

• accept :3:<path> for the 'theirs' index stage, like Git does.
  The parser had arms for stages 0, 1 and 2 and let everything else fall through
  to the catch-all, so :3:file was looked up as a path literally named
  3:file at stage 0. gitrevisions(7) documents a stage number of 0 to 3, and
  Git resolves :3:file to the blob from the branch being merged.

  The trait's own docs said stages range from 0 to 2 and labelled them base, ours
  and theirs. That is off by one: 0 is unconflicted, and 1, 2 and 3 are the common
  ancestor, the target branch and the branch being merged. The docs came first, in
  cee04e1, and the arms written twenty minutes later in ea22d3e matched them.

  This is marked breaking because a Navigate implementation written against the
  old documented range can now be handed a stage it does not expect. The one in
  gix already maps 3 to Stage::Theirs, but the one behind gix revision explain did not, which the next commit addresses.

Commit Statistics

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

Commit Details