From: Karthik Nayak Date: Mon, 07 Jul 2025 08:59:06 GMT Subject: Re: [PATCH v2 0/4] for-each-ref: introduce seeking functionality via '--skip-until' Message-ID: In-Reply-To: Junio C Hamano writes: > Karthik Nayak 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 ... > >> 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? > I do agree, I was modelling this after what would be the best approach within the Git codebase. But I think it would be nicer for the clients if we skip the provided reference. >> $ 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. > With that I think '--start-after' sounds like the best option. I'll modify for the next version accordingly. Thanks!