On Wed, Jul 02, 2025 at 03:33:47PM -0500, Karthik Nayak wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> 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
