Re: [PATCH 0/4] for-each-ref: introduce seeking functionality via '--skip-until'

From: Karthik Nayak <karthik.188@gmail.com>
Date: Jul 3, 2025, 08:48 UTC
Message-ID: <CAOLa=ZSN+Fvr0ixQWV0Becj-ELMRSkhm+POKF=BQ=F615sSj4A@mail.gmail.com>
In-Reply-To: <aGY9AyJ3c5wXpKaX@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 15 quoted lines

> On Wed, Jul 02, 2025 at 10:56:18PM -0700, Junio C Hamano wrote:
>> Patrick Steinhardt <ps@pks.im> writes:
>>
>> > Even more importantly though, a numeric offset would be invalidated by a
>> > concurrent write in case that write ends up inserting a ref in the range
>> > of commits you intend to skip now.
>>
>> That argument cuts both ways, no?  You have shown up to some ref
>> which you remember in the last cycle, and then while you are
>> planning to formulate another query with --skip-until naming that
>> ref, somebody removes that ref, then what happens?
>
> This ref was already yielded, and it wouldn't and shouldn't be yielded
> on the next page. This works as expected with the proposal, as
> `--skip-until` does not care whether the value itself actually exists.

The current version of the series will include the reference provided to '--skip-until', if it exists. But your latter statement still holds, if the reference doesn't exist, it will still work by finding the next reference in the default sort order.

Show 7 quoted lines

>> Or somebody inserts a new ref that sorts earlier than the ref you
>> stopped at the last time.
>
> It wouldn't and shouldn't be shown. When I have already yielded all refs
> up to refs/heads/something, I don't expect to see any ref that sorts
> before refs/heads/something on the next page.
>

Yeah, this was my thought too. Another way to think of this is that in a cursor based approach, a particular reference is guarateed never to occur again, even with modifications to the repository made between requests. However in a count based approach this doesn't stand.

> Patrick