What causes "Cannot use iter_v1() on index of type {:?}" in GitoxideLabs/gitoxide?

Use `index_file.iter()` instead, which dispatches to the correct version

Cannot use iter_v1() on index of type

Error message

Cannot use iter_v1() on index of type {:?}

What it means

`gix_pack::index::File::iter_v1()` only works on pack index version V1 (.idx v1). When called on any other version the match falls through to a `_ => panic!` arm. The public `iter()` wrapper normally dispatches by version, so hitting this panic means the version dispatch was bypassed or the caller assumed the wrong version.

Solutions

Use `index_file.iter()` instead, which dispatches to the correct version
Check `index_file.version` and only call `iter_v1()` when it equals `Version::V1`
Use `iter_v2()` for `Version::V2` indexes
Regenerate the index if you specifically need v1 semantics

Example fix

// before
let entries = index_file.iter_v1(); // panics on v2 indexes
// after
let entries = index_file.iter(); // dispatches correctly by version

Defensive patterns

Strategy: validation

Validate before calling

if index_file.version == gix_pack::index::Version::V1 {
    let entries: Vec<_> = index_file.iter_v1().collect();
} else {
    let entries: Vec<_> = index_file.iter().collect();
}

Type guard

fn supports_v1(index: &gix_pack::index::File) -> bool {
    index.version == gix_pack::index::Version::V1
}

Prevention

Always prefer the version-agnostic iter()
Log/assert index version when loading packs in mixed-version repos
Normalize repo indexes to v2 so version-specific calls are safe

When it happens

Trigger: Calling `index_file.iter_v1()` directly on a `gix_pack::index::File` whose `version` is `Version::V2`; hard-coding v1 access after loading a v2 index.

Common situations: Working with mixed repositories where some packs have v1 and others v2 indexes; code written against old repos then run on modern ones (git defaults to v2); writing custom pack iteration logic.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of GitoxideLabs/gitoxide@e73179060b (2026-09-08). Data as JSON: /api/errors/66e09d11d8740585. Report an issue: GitHub.

Appendix: source

Thrown at gix-pack/src/index/access.rs:47

/// Iteration and access
impl<T> index::File<T>
where
    T: crate::FileData,
{
    fn iter_v1(&self) -> impl Iterator<Item = Entry> + '_ {
        match self.version {
            index::Version::V1 => self.data[V1_HEADER_SIZE..]
                .chunks_exact(N32_SIZE + self.hash_len)
                .take(self.num_objects as usize)
                .map(|c| {
                    let (ofs, oid) = c.split_at(N32_SIZE);
                    Entry {
                        oid: gix_hash::ObjectId::from_bytes_or_panic(oid),
                        pack_offset: u64::from(crate::read_u32(ofs)),
                        crc32: None,
                    }
                }),
            _ => panic!("Cannot use iter_v1() on index of type {:?}", self.version),
        }
    }

    fn iter_v2(&self) -> impl Iterator<Item = Entry> + '_ {
        let pack64_offset = self.offset_pack_offset64_v2();
        let oids = self.data[V2_HEADER_SIZE..]
            .chunks_exact(self.hash_len)
            .take(self.num_objects as usize);
        let crcs = self.data[self.offset_crc32_v2()..]
            .as_chunks::<N32_SIZE>()
            .0
            .iter()
            .take(self.num_objects as usize);
        let offsets = self.data[self.offset_pack_offset_v2()..]
            .as_chunks::<N32_SIZE>()
            .0
            .iter()
            .take(self.num_objects as usize);

View on GitHub (pinned to e73179060b)