From: Junio C Hamano <gitster@pobox•com>
To: Karthik Nayak <karthik.188@gmail•com>
Cc: Patrick Steinhardt <ps@pks•im>,
git@vger•kernel.org, schwab@linux-m68k•org,
phillip.wood123@gmail•com
Subject: Re: [PATCH v3 3/4] refs: selectively set prefix in the seek functions
Date: Wed, 16 Jul 2025 13:02:05 -0700 [thread overview]
Message-ID: <xmqqfrevc3b6.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZTc2_g3+8MM8whW+eZAj-+36HNsnUFDoLgnN42ytFLwAw@mail.gmail.com> (Karthik Nayak's message of "Wed, 16 Jul 2025 07:40:30 -0700")
Karthik Nayak <karthik.188@gmail•com> writes:
> Let's say a user is iterating with a prefix set to 'refs/heads/', this
> would iterate over all the refs with that prefix. But mid-way the user
> realizes that they only care about 'refs/heads/feature/' prefix and they
> ask the iterator to set that as the prefix.
>
> In such a situation, the iterator seeks to 'refs/heads/feature/' and
> will only yield references with that prefix. In short, the previous
> prefix state was reset.
Yes, even though I wouldn't call such an operation "seek", "Ah, I do
not need the entire refs/heads/ walked, only refs/heads/feature/ is
enough" is an operation mode that makes sense.
But not for paging, though.
If your web application is showing all branches, one pageful at a
time, and the first page ended at refs/heads/feature/something and
you ended up "seeking" to refs/heads/feature/ to start the second
page, you do not want your second page to end when the iteration
goes out of refs/heads/feature/ hierarchy, no?
It seems to me that the root cause of the confusion is because
prefix, which is to let iteration finish way before the data runs
out (instead finish when the iteration steps out of a given
subhierarchy denoted by the prefix), is somehow abused as the
current position of the cursor. Shouldn't they be two separate
concepts? The cursor needs to fall within the prefix while the
iterator is active, so they are not two totally independent things,
but prefix is pretty much static while the cursor position is very
dynamic.
> This series did start out that way around, so ease of implementation
> isn't it. It was more of a side-effect of not clearing state.
I am even more worried about usability and correctness aspect of
what was described here now. After seeking to refs/heads/feature/,
do we continue to iterate and step out of refs/heads/feature/
hierarchy or can we cut off a particular page that started with a
ref within refs/heads/feature/ subhierarchy when we exhaust refs in
refs/heads/feature/ and have to wait for getting asked for the next
page before we show refs/heads/gsomething that is outside
refs/heads/feature/ and sorts after? The "I reset to iterate over
refs/heads/feature/ because the entire refs/heads/ is not what I
care about" example makes me worried about this.
Thanks.
next prev parent reply other threads:[~2025-07-16 20:02 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 15:03 [PATCH 0/4] for-each-ref: introduce seeking functionality via '--skip-until' Karthik Nayak
2025-07-01 15:03 ` [PATCH 1/4] refs: expose `ref_iterator` via 'refs.h' Karthik Nayak
2025-07-01 15:03 ` [PATCH 2/4] ref-cache: remove unused function 'find_ref_entry()' Karthik Nayak
2025-07-14 15:46 ` Junio C Hamano
2025-07-01 15:03 ` [PATCH 3/4] refs: selectively set prefix in the seek functions Karthik Nayak
2025-07-03 5:55 ` Patrick Steinhardt
2025-07-03 9:40 ` Karthik Nayak
2025-07-01 15:03 ` [PATCH 4/4] for-each-ref: introduce a '--skip-until' option Karthik Nayak
2025-07-03 5:55 ` Patrick Steinhardt
2025-07-03 10:02 ` Karthik Nayak
2025-07-03 10:59 ` Patrick Steinhardt
2025-07-01 17:08 ` [PATCH 0/4] for-each-ref: introduce seeking functionality via '--skip-until' Junio C Hamano
2025-07-02 16:45 ` Karthik Nayak
2025-07-01 21:37 ` Junio C Hamano
2025-07-02 18:19 ` Karthik Nayak
2025-07-03 8:41 ` Karthik Nayak
2025-07-02 14:14 ` Phillip Wood
2025-07-02 20:33 ` Karthik Nayak
2025-07-03 5:18 ` Patrick Steinhardt
2025-07-03 5:56 ` Junio C Hamano
2025-07-03 8:19 ` Patrick Steinhardt
2025-07-03 8:48 ` Karthik Nayak
2025-07-04 13:02 ` [PATCH v2 " Karthik Nayak
2025-07-04 13:02 ` [PATCH v2 1/4] refs: expose `ref_iterator` via 'refs.h' Karthik Nayak
2025-07-04 13:02 ` [PATCH v2 2/4] ref-cache: remove unused function 'find_ref_entry()' Karthik Nayak
2025-07-04 13:02 ` [PATCH v2 3/4] refs: selectively set prefix in the seek functions Karthik Nayak
2025-07-04 13:02 ` [PATCH v2 4/4] for-each-ref: introduce a '--skip-until' option Karthik Nayak
2025-07-07 15:30 ` Junio C Hamano
2025-07-07 18:31 ` Karthik Nayak
2025-07-04 13:41 ` [PATCH v2 0/4] for-each-ref: introduce seeking functionality via '--skip-until' Andreas Schwab
2025-07-04 14:02 ` Karthik Nayak
2025-07-04 14:52 ` Andreas Schwab
2025-07-04 14:58 ` Karthik Nayak
2025-07-04 15:55 ` Andreas Schwab
2025-07-07 8:52 ` Karthik Nayak
2025-07-04 16:39 ` Junio C Hamano
2025-07-07 8:59 ` Karthik Nayak
2025-07-07 9:45 ` Phillip Wood
2025-07-08 11:39 ` Karthik Nayak
2025-07-08 13:47 ` [PATCH v3 0/4] for-each-ref: introduce seeking functionality via '--start-after' Karthik Nayak
2025-07-08 13:47 ` [PATCH v3 1/4] refs: expose `ref_iterator` via 'refs.h' Karthik Nayak
2025-07-08 13:47 ` [PATCH v3 2/4] ref-cache: remove unused function 'find_ref_entry()' Karthik Nayak
2025-07-08 13:47 ` [PATCH v3 3/4] refs: selectively set prefix in the seek functions Karthik Nayak
2025-07-10 6:44 ` Patrick Steinhardt
2025-07-11 9:44 ` Karthik Nayak
2025-07-14 16:09 ` Junio C Hamano
2025-07-15 9:49 ` Karthik Nayak
2025-07-15 16:35 ` Junio C Hamano
2025-07-16 14:40 ` Karthik Nayak
2025-07-16 15:39 ` Junio C Hamano
2025-07-16 20:02 ` Junio C Hamano [this message]
2025-07-17 9:01 ` Karthik Nayak
2025-07-17 17:31 ` Junio C Hamano
2025-07-08 13:47 ` [PATCH v3 4/4] for-each-ref: introduce a '--start-after' option Karthik Nayak
2025-07-08 20:25 ` Junio C Hamano
2025-07-09 9:53 ` Karthik Nayak
2025-07-11 16:18 ` [PATCH v4 0/4] for-each-ref: introduce seeking functionality via '--start-after' Karthik Nayak
2025-07-11 16:18 ` [PATCH v4 1/4] refs: expose `ref_iterator` via 'refs.h' Karthik Nayak
2025-07-11 16:18 ` [PATCH v4 2/4] ref-cache: remove unused function 'find_ref_entry()' Karthik Nayak
2025-07-11 16:18 ` [PATCH v4 3/4] refs: selectively set prefix in the seek functions Karthik Nayak
2025-07-14 10:34 ` Christian Couder
2025-07-15 8:19 ` Karthik Nayak
2025-07-11 16:18 ` [PATCH v4 4/4] for-each-ref: introduce a '--start-after' option Karthik Nayak
2025-07-14 16:04 ` Christian Couder
2025-07-14 16:42 ` Junio C Hamano
2025-07-15 8:42 ` Karthik Nayak
2025-07-14 16:34 ` [PATCH v4 0/4] for-each-ref: introduce seeking functionality via '--start-after' Christian Couder
2025-07-14 16:49 ` Junio C Hamano
2025-07-15 9:49 ` Karthik Nayak
2025-07-15 11:28 ` [PATCH v5 0/5] " Karthik Nayak
2025-07-15 11:28 ` [PATCH v5 1/5] refs: expose `ref_iterator` via 'refs.h' Karthik Nayak
2025-07-15 11:28 ` [PATCH v5 2/5] ref-cache: remove unused function 'find_ref_entry()' Karthik Nayak
2025-07-17 14:48 ` Junio C Hamano
2025-07-17 19:31 ` Karthik Nayak
2025-07-17 20:32 ` Junio C Hamano
2025-07-15 11:28 ` [PATCH v5 3/5] refs: selectively set prefix in the seek functions Karthik Nayak
2025-07-17 2:09 ` Jeff King
2025-07-17 19:49 ` Karthik Nayak
2025-07-17 21:55 ` Jeff King
2025-07-15 11:28 ` [PATCH v5 4/5] ref-filter: remove unnecessary else clause Karthik Nayak
2025-07-15 11:28 ` [PATCH v5 5/5] for-each-ref: introduce a '--start-after' option Karthik Nayak
2025-07-17 15:31 ` Junio C Hamano
2025-07-22 8:07 ` Karthik Nayak
2025-07-15 19:00 ` [PATCH v5 0/5] for-each-ref: introduce seeking functionality via '--start-after' Junio C Hamano
2025-07-17 1:19 ` Kyle Lippincott
2025-07-17 1:54 ` Jeff King
2025-07-17 17:08 ` Kyle Lippincott
2025-07-17 19:26 ` Karthik Nayak
2025-07-17 19:35 ` Kyle Lippincott
2025-07-17 22:09 ` Jeff King
2025-07-17 22:16 ` Jeff King
2025-07-21 14:27 ` Karthik Nayak
2025-07-21 21:22 ` Jeff King
2025-07-22 8:44 ` Karthik Nayak
2025-07-17 22:21 ` Junio C Hamano
2025-07-23 21:51 ` [PATCH] ref-iterator-seek: correctly initialize the prefix_state for a new level Junio C Hamano
2025-07-23 21:57 ` Kyle Lippincott
2025-07-23 23:52 ` Jeff King
2025-07-24 8:12 ` Karthik Nayak
2025-07-24 17:01 ` Junio C Hamano
2025-07-24 22:11 ` [PATCH] ref-cache: set prefix_state when seeking Karthik Nayak
2025-07-24 22:30 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqfrevc3b6.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=karthik.188@gmail$(echo .)com \
--cc=phillip.wood123@gmail$(echo .)com \
--cc=ps@pks$(echo .)im \
--cc=schwab@linux-m68k$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox