refs.references().prefixed() lets too many refs through

[moroten]

Current behavior 😯

Some refs reported by repo.references()?.prefixed(...) are outside the prefix scope. The refs that are reported are loose refs which are not present in .git/packed-refs.

This has been tested with gix=0.71.0 and overriding with gix-features=0.41.1.

Relates to #1928 with the PR #1931.

Expected behavior 🤔

Only refs that starts with the prefix are reported.

Git behavior

No response

Steps to reproduce 🕹

Create .git/refs/heads/foo/bar. That ref will be listed with repo.references()?.prefixed("refs/heads/b").

[Byron]

Thanks for reporting, I am looking forward to a reproduction.

While #1931 kind of 'winged' it, for a fix here we might have to go and check what Git really does. In theory, loose and packed refs 'just' have to be sorted the same way for this to work. And of course, in case of prefixed, they have to start at the same position.

Maybe one of these factors is still off.

[moroten]

In 293bfc0#diff-f8ebed64b52627e407b8ee19c33669e60975b015557005c518ac5a0c1c29e599R49-R57, the component of a ref is compared to the last component of the prefix. The full path is also compared to the prefix without the last component. This means that refs/heads/prefix will match refs/heads/some/path/prefix-suffix.

[moroten]

It turns out that prefix refs/heads/foo matches refs/heads/foo-suffix and refs/heads/sub/dir/foo, but the documentation of [gix_ref::store_impl::file::overlay_iter::Platform::prefixed](https://github.com/GitoxideLabs/gitoxide/blob/1612c73a16c8d900e1b6ef35b25bd6b3e3f6652a/gix-ref/src/store/file/overlay_iter.rs#L200) says:

Please note that "refs/heads" or "refs\heads" is equivalent to "refs/heads/"

[moroten]

What is the contract for the Platform::prefixed()? 293bfc0 talks about letting the prefix refs/heads/foo match refs/heads/foo-suffix whereas the implementation for loose refs documents that refs/heads/foo behaves like refs/heads/foo/ as prefix. Should there be multiple API functions to reduce the confusion? Is there a git API that Gitoxide is trying to mimic?

I've created the PR #1936 to at least not match refs/heads/sub/dir/foo.

[Byron]

It turns out that prefix refs/heads/foo matches refs/heads/foo-suffix and refs/heads/sub/dir/foo, but the documentation of [gix_ref::store_impl::file::overlay_iter::Platform::prefixed](https://github.com/GitoxideLabs/gitoxide/blob/1612c73a16c8d900e1b6ef35b25bd6b3e3f6652a/gix-ref/src/store/file/overlay_iter.rs#L200) says:

Please note that "refs/heads" or "refs\heads" is equivalent to "refs/heads/"

Thanks so much for dissecting this!

I think we are onto something here, maybe a confusion due to dissimilarities between the prefixed loose reference iteration and prefixed packed-refs iterations.

refs/heads/foo from what I recall should match refs/heads/foo-suffix, but it shoudl definitely not match refs/heads/sub/dir/foo which it seems to do currently.

Maybe these simple tests could be added in #1936 both for packed and loose refs and see where we land, also for (prefixed) iteration.

If there are differences, it's clear why this happens, and yet another test using the overlay iterator could verify that the new implementation is indeed correct.

And… I'd really appreciate your help here, from what I can tell you are really close to a solution and with your familiarity with editing/creating tests I think it should be convenient to iterate (no pun intended 😅) towards a solution.