fix(deps): update rust crate gix to 0.85#599
Open
ferrlabs-renovate[bot] wants to merge 1 commit into
Open
Conversation
ferrlabs-renovate
Bot
force-pushed
the
renovate/gix-0.x
branch
from
da505b6 to
2f54961
Compare
Contributor
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.84→0.85Release Notes
GitoxideLabs/gitoxide (gix)
v0.85.0: gix v0.85.0Compare Source
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
Connectionlifetimes,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
continueis 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
gixhad 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 --shortexits 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-levelNotADirectoryerror whenrefs/heads/Aalready exists as a loose ref. Thatlookup 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.hdocumentsENOTDIRas the case where aref prefix is not a directory, alongside
ENOENTfor non-existing refs. Forlookup, 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 relativefiles.
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 clonesetup treated the requested name as a branch and generated a refspec
under
refs/heads/. For tag names this produced an unmatched requiredmapping 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 tothemselves.
Baseline Git behavior was checked with
/Users/byron/dev/github.com/git/git:non-shallow
--branch <tag>clones keep the normal branch wildcardfetch refspec, while shallow
--depth 1 --branch <tag>clones store+refs/tags/<tag>:refs/tags/<tag>.reject deleted prior checkout branches
Commit Statistics
Commit Details
view details
9ad2e24)6b5c2ea)6730316)da6b267)9929ece)ed998d1)325d2a1)470e689)77e11be)28b726d)e7c7484)a8c5257)00f64fc)fa42565)3755396)590b206)f051396)Editor::remove_leaf()(cd610db)73ffc99)847eb4a)5217d66)52d26d7)discovery_optsto inform aboutupwards::Optionstrust handling. (7ba53e1)f1f8b6f)2a5b8d4)5dfb44d)3b4a6bc)c391a12)14a1a11)ad9354e)b859b92)b0155ce)4f089fc)9f432ef)5aadd6e)137794d)b5b2d54)bc4064c)69caccd)gix_object::Write::*with_known_id()and use it. (2bd9dfe)a209dc1)1d80b47)bd2881e)3dd621c)0c1645a)find_custom_refnameas in Git (7734fb0)92c8130)a4be01b)f7d4f33)Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate.