Re: [PATCH 0/4] for-each-ref: introduce seeking functionality via '--skip-until'
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Jul 3, 2025, 05:18 UTC
- Message-ID
- <aGYSjf5H_ZBaVVJm@pks.im>
- In-Reply-To
- <CAOLa=ZTwvOiCnYK18GTEUkcW0-YLHkJ=MBggdzOYsbTT+OHPwQ@mail.gmail.com>
On Wed, Jul 02, 2025 at 03:33:47PM -0500, Karthik Nayak wrote:
Show 30 quoted lines
> Phillip Wood <phillip.wood123@gmail.com> writes: > > Hello Phillip, > > > Hi Karthik > > > > On 01/07/2025 16:03, Karthik Nayak wrote: > >> > >> This enables efficient pagination workflows like: > >> git for-each-ref --count=100 > >> git for-each-ref --count=100 --skip-until=refs/heads/branch-100 > >> git for-each-ref --count=100 --skip-until=refs/heads/branch-200 > > > > Doesn't that require you to know the name of the ref after the last one > > returned by the previous batch? If the use case here is pagination then > > being able to provide a numeric offset might be a better fit. For example > > > > It does require that you know the last ref from the previous batch. > > The reason for picking a reference offset is mostly for performance > optimization. Our reference backends are built with prefix matching in > mind, in short they do a binary search through the reference namespace > to find the required prefix. By using a reference offset we can utilize > this binary search mechanism to arrive at offset. > > Using a count offset would require iteration to reach the desired > offset (basically a O(N) operation). This wouldn't really matter in > repositories with ~10^3 refs, but in larger repositories with around > ~10^6 refs this starts to make a large difference.
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.
Patrick