GitoxideLabs/gitoxide · error
infallible name conversion
Error message
infallible name conversion
What it means
This is a panic (not a returned error) raised by `.expect("infallible name conversion")` inside `log_exists` in gix-ref's file store. The code converts a partial reference name to a fully qualified one via `reflog_exists`, which the developers assert can never fail because the name has already been validated as a partial ref name earlier in the pipeline. A panic here therefore indicates an internal bug in gix-ref's name validation, not a user-correctable condition.
Solutions
- Report the panic as a bug to the gitoxide project with the ref name and stack trace.
- Verify the ref name being queried is a well-formed partial ref name (no invalid characters, correct `refs/...` shape).
- Pin or update the gix/gix-ref version to one where the name-conversion invariant holds.
Defensive patterns
Strategy: validation
Validate before calling
// gix: validate the partial ref name before querying reflogs
if gix_ref::name::partial::check_ref_name_valid(name.as_ref()).is_err() {
return Err("invalid ref name".into());
}
let exists = repo.reflog_exists(name)?; Prevention
- Validate ref names with gix's own name checks before any ref/reflog API call.
- Treat panics inside gix-ref as bugs and capture the ref name in bug reports.
- Pin gix versions and read changelogs for name-validation changes.
When it happens
Trigger: Calling `Repository::reflog_exists()` (or any path that reaches `gix_ref::store::file::raw_ext::log_exists`) when the internally stored partial name fails to convert to a full reference name — which per the invariant should be impossible.
Common situations: Essentially never hit by correct usage. Could surface during a gix-ref/gix version upgrade if name-validation logic changed, or when operating on unusual ref names (e.g. unusual casing or encoding) that expose a validation gap.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- name conversion infallible
- only value and unspecified are possible here
- parent-match assures this
- upper match already assured we only deal with blobs
- fixed size array with three items
AI-assisted analysis of GitoxideLabs/gitoxide@e73179060b (2026-09-08).
Data as JSON: /api/errors/9554f27f9c02cb1a.
Report an issue: GitHub.
Appendix: source
Thrown at gix-ref/src/store/file/raw_ext.rs:114
&self,
store: &file::Store,
packed: Option<&packed::Buffer>,
) -> Option<Result<Reference, file::find::existing::Error>>;
}
impl ReferenceExt for Reference {
fn log_iter<'a, 's>(&'a self, store: &'s file::Store) -> log::iter::Platform<'a, 's> {
log::iter::Platform {
store,
name: self.name.as_ref(),
buf: Vec::new(),
}
}
fn log_exists(&self, store: &file::Store) -> bool {
store
.reflog_exists(self.name.as_ref())
.expect("infallible name conversion")
}
fn peel_to_id_in_place(
&mut self,
store: &file::Store,
objects: &dyn gix_object::Find,
) -> Result<ObjectId, peel::to_id::Error> {
self.peel_to_id(store, objects)
}
fn peel_to_id(
&mut self,
store: &file::Store,
objects: &dyn gix_object::Find,
) -> Result<ObjectId, peel::to_id::Error> {
let packed = store.assure_packed_refs_uptodate().map_err(|err| {
peel::to_id::Error::FollowToObject(peel::to_object::Error::Follow(file::find::existing::Error::Find(
file::find::Error::PackedOpen(err),View on GitHub (pinned to e73179060b)