Patrick Steinhardt <ps@xxxxxx> writes: > On Wed, Jul 02, 2025 at 10:56:18PM -0700, Junio C Hamano wrote: >> Patrick Steinhardt <ps@xxxxxx> 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. >> 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
Attachment:
signature.asc
Description: PGP signature
