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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 16, 2025, 20:02 UTC
Message-ID: <xmqqfrevc3b6.fsf@gitster.g>
In-Reply-To: <CAOLa=ZTc2_g3+8MM8whW+eZAj-+36HNsnUFDoLgnN42ytFLwAw@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

Show 8 quoted lines

> 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.