GitoxideLabs/gitoxide gix-v0.85.0

gix v0.85.0

on GitHub

Bug Fixes (BREAKING)

• avoid duplicate network connection when adopting a remote-controlled hash kind.
  Connections can now be created from detached remotes, internally,
  which makes them independent of the underlying repository.

  This is breaking as it comes with a cleanup of Connection lifetimes,
  which will break anyone who stores them in a struct. So hopefully
  nobody is affected.

• bound the clone object-hash adoption retry
  The clone fetch loop adopts the remote's object format and retries when
  it differs from the freshly initialized local repository. Adoption makes
  the next iteration's hashes match, but if the reopened repository somehow
  still disagrees the loop would re-handshake forever. Track whether we
  already retried and fail with IncompatibleObjectHash on a second mismatch
  instead. The error variant is introduced here, as this is its only user.

  Also silence clippy::never_loop on default (sha1) features, where the
  sha256-gated continue is absent and the loop always returns first pass.

New Features (BREAKING)

• add leaf-only tree-editor removal via Editor::remove_leaf()
  Motivation comes from gitbutlerapp/gitbutler#14312,
  where callers had to split tree-entry deletions from additions to avoid
  accidentally deleting a newly-added subtree after adding A/one and then deleting
  A.

  Add Editor::remove_leaf() to gix-object and expose it through gix object tree
  editors and cursors. The new API keeps remove() behavior unchanged, remains
  tolerant of absent paths, but returns an error when the target entry exists and
  is a tree.

Bug Fixes

• adopt the remote's object format when cloning
  A clone into a freshly initialized repository hit an unimplemented!
  panic when the remote used sha256, since the local repository defaults
  to sha1.

  Reconfigure the still-empty local repository to the remote's object
  format and retry the fetch, matching git's behavior of inheriting
  the remote's hash on clone.

  Without the sha256 feature gix_hash::Kind has a single variant, so the
  local and remote hashes can never differ; the mismatch check is compiled
  out entirely in that case.

• write fetched remote symrefs as direct refs
  Previously gix had made-up behaviour to 'improve' on standard Git,
  but it's clear this isn't backed up or tested well enough to be worth
  the risk of introducing subtle or not so subtle bugs.

• resolve remote HEAD fetches against remote refs
  Fetching a local transport remote with a refspec like +HEAD:refs/test/repo could
  write a symbolic local ref to the client repository's refs/heads/main when the
  remote HEAD was symbolic and the client happened to have a same-named branch.
  That made the fetched destination resolve to the local branch instead of the
  remote HEAD object.

  Add a fetch regression that creates distinct local and remote
  repositories with matching HEAD target names but different commits, then fetches
  +HEAD:refs/test/repo and asserts the destination is the remote object as a
  direct ref.

  Match Git behavior observed with the local Git checkout: git fetch
  +HEAD:refs/test/repo creates refs/test/repo as the remote HEAD object, and Git's
  remote.c resolves symrefs against the advertised remote ref list.

  Fix the unmapped remote-symbolic-ref fallback to peel born remote symrefs to
  their advertised object id instead of consulting local refs. Mapped symrefs
  still rewrite to their corresponding local tracking ref, and unborn remote refs
  remain symbolic.

• set trust for GIT_DIR environment discovery
  A Helix user reported that opening a repository with GIT_DIR set could panic in
  gix while discovering a repository through environment overrides. The reported
  reproductions used GIT_DIR=.git with Helix or git --git-dir=.git invoking an
  editor, and the panic came from open_from_paths() expecting git-dir trust to
  have already been determined.

  The GIT_DIR override path in open_with_environment_overrides() already
  determines ownership trust for the effective git directory and selects options
  from the trust mapping, but it did not store that trust in the Options passed to
  open_from_paths(). Store the determined trust there, matching discover_opts(),
  so configuration loading receives an explicit trust value instead of reaching
  the internal expect().

  Git baseline: git --git-dir=<repo/.git> --work-tree=<repo> status --short exits successfully.

• reject implicit sha1 repos in sha256-only builds
  A missing extensions.objectFormat means legacy Sha1.

  In sha256-only builds, Kind::default() is Sha256, so such repos
  were silently mislabeled as Sha256.

  Resolve the implicit case to Sha1 when supported, else error
  out to avoid any mislabeling.

  Also reject extensions.objectFormat when repositoryFormatVersion is 0,
  matching git, which treats it as an invalid v1-only extension.

• handle loose ref path-prefix collisions
  The GitButler branch creation flow reported that
  repo.try_find_reference("refs/heads/A/new") could fail with a low-level
  NotADirectory error when refs/heads/A already exists as a loose ref. That
  lookup is asking whether the longer ref exists; the path-prefix collision
  matters to creation/update code, but find should report absence for that
  candidate.

  Git reference: refs/refs-internal.h documents ENOTDIR as the case where a
  ref prefix is not a directory, alongside ENOENT for non-existing refs. For
  lookup, both mean the requested ref candidate was not found.

• write new remote sections to the local config file.

• Add support for gix_object::Write::*with_known_id() and use it.
  This means the Repository::write_object() won't recalculate the hash.

• handle relative worktree gidir files
  Git 2.48 can link worktrees with relative paths. In that layout the checkout
  .git file points at the private git dir relative to the checkout, while
  worktrees//gitdir points back to the checkout relative to the private git
  dir.

  Discovery already handled the checkout-side gitdir file, but paths read from the
  private git dir were treated as-is. That made discovery from .git/worktrees/
  and Repository::worktrees() proxy base resolution produce relative paths
  anchored to the process cwd instead of the gitdir file location.

  Git reference: /Users/byron/dev/github.com/git/git
  worktree.c:write_worktree_linking_files writes both relative links with
  relative_path(), and t/t2400-worktree-add.sh covers the resulting relative
  files.

• fetching and cloning with refspecs that are tags (in shallow clones)
  Fix shallow clone refspecs for explicit tag refs

  When a shallow clone was created with with_ref_name(), the clone
  setup treated the requested name as a branch and generated a refspec
  under refs/heads/. For tag names this produced an unmatched required
  mapping like +refs/heads/<tag>:refs/remotes/origin/<tag>.

  Resolve the requested ref name against the remote before constructing
  the shallow single-ref refspec. Branches continue to map to
  refs/remotes/<remote>/*, while tags and other non-branch refs map to
  themselves.

  Baseline Git behavior was checked with /Users/byron/dev/github.com/git/git:
  non-shallow --branch <tag> clones keep the normal branch wildcard
  fetch refspec, while shallow --depth 1 --branch <tag> clones store
  +refs/tags/<tag>:refs/tags/<tag>.

• reject deleted prior checkout branches

Commit Statistics

• 49 commits contributed to the release over the course of 27 calendar days.
• 27 days passed between releases.
• 14 commits were understood as conventional.
• 3 unique issues were worked on: #1951, #2609, #2613

Commit Details