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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 4, 2025, 16:39 UTC
Message-ID: <xmqqa55jc3md.fsf@gitster.g>
In-Reply-To: <CAOLa=ZS0uP+5xso_SEG2GJZHeac-0F2_wMJKtvbFj_wROKbBkw@mail.gmail.com>

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

> I think I was a bit against '--start-from' and '--start-at', because
> they imply that the reference provided must exist.

It also implies that if the reference does exist, that would be the first one that is shown. But I do not think you want that, as ...

Show 6 quoted lines

> Consider the example
>
>   $ git for-each-ref
>   refs/heads/bar
>   refs/heads/foo
>   refs/heads/main

... after a paging application starts from the beginning and showed a single page of some items, it knows the "last" one it showed. That last entry may have been refs/heads/bar. The application may not have seen the next entry (i.e. refs/heads/foo). So if it has to use '--start-at=refs/heads/bar', the first entry it gets from such a request may be for refs/heads/bar again. The application needs to remember the "last" one it showed and skip that, which is a bit awkward, isn't it?

Show 6 quoted lines

>   $ git for-each-ref --seek=refs/heads/cat
>   refs/heads/foo
>   refs/heads/main
>
> You can see that the reference doesn't have to exist. So implying that
> it should can be a bit confusing.

For that reason, whatever verb you pick from seek or start or skip, it would be great if the option name also made it explicit that the named one, if exists, is not shown. Conceptually, it is "skip everything that sorts before the named item, including the named item itself" that such a paging application would want, wouldn't it?

Thanks.