feat: refs support pseudo refs

[orthros]

Adds support in the references iter Platform to iterate over the pseudo references in the repository.

Note that the all funciton will not return pseudo references to maintain backwards compatibility.

[Byron]

Thanks for contributing this and I see how it can be useful!

I set it back to draft as there are no tests which are strictly required. Is this something you'd want to continue on?

If so, I have some additional notes below.
And after writing them I think that iter_pseudo_refs() should better be its own iterator to avoid all these max_depth related changes entirely.

[orthros]

I believe I addressed your concerns. PLMK what you think!

[Byron]

Thanks so much!

I believe I addressed your concerns. PLMK what you think!

First of all, apologies for not responding to the comment above - I somehow missed it, which might just mean that I archived the email without actually acting on it, which was my intent.
This makes it even more unfortunate that what I wanted to say is along the lines of "I see what you mean, let's stick to keeping the SortedLoosePaths version", instead of creating a separate iterator.

Would you be willing to roll that back?

If you are out of time, just let me know and I will do it. Please note that I will have to rewrite your commits though as the commit-separation isn't addressed yet. (The 'adapt' commits are missing, and as a rule of thump here, changes to a single crate have to go into their own commits).

[Byron]

Further, it seems like git2 lists pseudo-refs as well when listing all references (there seems to be no differentiation in listing methods), and it's something that gitoxide should also consider.

With the current iterator setup it's not super trivial to do in gix-refs, but gix could probably build something around it and instead do two iterations if it wanted to. I wouldn't be sure if all() should be changed though, and am very sure that this doesn't have to be part of this PR. In any case, if there is interest from your side, it's something we could tackle in a follow-up.

[orthros]

If I had a dollar for every time I accidentally archived an email I meant to respond to I'd be retired!

Totally fine rolling it back! I won't be able to do so until early next week.

Also I see I split the adapt commit into one but not the other.

IIRC this broke the commit from compiling. Is that acceptable to have a non compiling commit in the chain?

[Byron]

Thanks so much!

IIRC this broke the commit from compiling. Is that acceptable to have a non compiling commit in the chain?

Yes, that's the trade-off to get changelog entries that fit for the respective crate. Otherwise, say, a breaking change would cause two crates to get a minor version bump, the one that actually broke, and the one that just adapted to the breaking change in a private API, along with changelog entries for both.

Totally fine rolling it back! I won't be able to do so until early next week.

No problem, I am looking forward to getting this merged.

[orthros]

Okay. now I think I have addressed the issues/comments. PLMK what you think!