Subject: Re: [PATCH v3 3/4] refs: selectively set prefix in the seek functions

From: Junio C Hamano <[email-masked]>
Date: Wed, 16 Jul 2025 13:02:05 -0700

Karthik Nayak <[email-masked]> writes:

> Let's say a user is iterating with a prefix set to 'refs/heads/', this
> would iterate over all the refs with that prefix. But mid-way the user
> realizes that they only care about 'refs/heads/feature/' prefix and they
> ask the iterator to set that as the prefix.
>
> In such a situation, the iterator seeks to 'refs/heads/feature/' and
> will only yield references with that prefix. In short, the previous
> prefix state was reset.

Yes, even though I wouldn't call such an operation "seek", "Ah, I do
not need the entire refs/heads/ walked, only refs/heads/feature/ is
enough" is an operation mode that makes sense.

But not for paging, though.

If your web application is showing all branches, one pageful at a
time, and the first page ended at refs/heads/feature/something and
you ended up "seeking" to refs/heads/feature/ to start the second
page, you do not want your second page to end when the iteration
goes out of refs/heads/feature/ hierarchy, no?

It seems to me that the root cause of the confusion is because
prefix, which is to let iteration finish way before the data runs
out (instead finish when the iteration steps out of a given
subhierarchy denoted by the prefix), is somehow abused as the
current position of the cursor.  Shouldn't they be two separate
concepts?  The cursor needs to fall within the prefix while the
iterator is active, so they are not two totally independent things,
but prefix is pretty much static while the cursor position is very
dynamic.

> This series did start out that way around, so ease of implementation
> isn't it. It was more of a side-effect of not clearing state.

I am even more worried about usability and correctness aspect of
what was described here now.  After seeking to refs/heads/feature/,
do we continue to iterate and step out of refs/heads/feature/
hierarchy or can we cut off a particular page that started with a
ref within refs/heads/feature/ subhierarchy when we exhaust refs in
refs/heads/feature/ and have to wait for getting asked for the next
page before we show refs/heads/gsomething that is outside
refs/heads/feature/ and sorts after?  The "I reset to iterate over
refs/heads/feature/ because the entire refs/heads/ is not what I
care about" example makes me worried about this.

Thanks.