From: Patrick Steinhardt <ps@pks•im>
To: Junio C Hamano <gitster@pobox•com>
Cc: Jeff King <peff@peff•net>,
git@vger•kernel.org,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>,
Karthik Nayak <karthik.188@gmail•com>,
Taylor Blau <me@ttaylorr•com>, Justin Tobler <jltobler@gmail•com>
Subject: Re: [PATCH v2 00/14] refs: improvements and fixes for peeling tags
Date: Tue, 14 Oct 2025 08:31:39 +0200 [thread overview]
Message-ID: <aO3uSz-idPWahgw7@pks.im> (raw)
In-Reply-To: <xmqq8qhibwrn.fsf@gitster.g>
On Fri, Oct 10, 2025 at 08:29:32AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks•im> writes:
>
> > So to move forward, how about we land this as-is and I promise to follow
> > up with another series that:
> >
> > - Renames `struct ref` as proposed.
> >
> > - Introduces `struct reference` into more of our APIs?
>
> Sorry, but I am not quite sure why we would want to do so.
>
> Does "struct reference" sufficiently cover the things we want to do
> with references and "struct ref" is not sufficient for that?
>
> Comparing what 'struct ref' caters to its users and what 'struct
> reference' offers to its users and declaring that one set of needs
> is more generic to the 'reference API' than the other set risks
> getting blinded by the area we happened to have been focusing on
> recently.
>
> Apparently, the above proposal is not claiming that what one wants
> to do is a subset of what the other wants to do (if so, you'd rather
> not be introducing a new "struct reference" but extending "struct
> ref" to be usable for more things).
>
> Or would we add more to it than what we see in this series, such
> that it would no longer be "a subset" of needs various code paths
> would have around the reference API? If so, is the longer-term plan
> to have callers that use "struct ref" to eventually use "struct
> reference"?
>
> If not, they are serving different subset of the problem space, and
> they will continue to do so. In that case, why wouldn't we rename
> "struct reference" to something that is more focused on what it is
> for? In the context of this topic, would that be "reference found
> during iteration" or something?
I think that `struct ref` and `struct reference` serve quite distinct
use cases. `struct ref` is all around references in the context of a
remote: they are only in our code that interacts with them like for
example "transport.c", "walker.c", "fetch-pack.c" and so on. As such,
this structure naturally contains a ton of fields that are relevant in
this context:
- It's a linked list that identifies all refs part of such a push.
- It contains new_old object IDs.
- It contains information whether or not such a reference should be
force-updated.
- It contains information whether the remote side has such a ref in
the first place.
- It encodes the FETCH_HEAD status.
There's much more, and nothing of this has anything to do with a plain
reference. As such, this type would be a very bad fit for use in the
"refs.c" subsystem, as the basic concepts are mismatching.
So what I'm proposing here is to introduce a `struct reference` that
really only cares about the specific concept of a plain reference. That
struct would thus only carry information that can be yielded by the ref
backends standalone.
The benefit is that it allows us to have a better abstraction boundary,
and it allows us to achieve things we cannot easily do right now. For
example, if functions like `refs_read_ref()` returned such a structure,
then we can now also peel such a ref with `reference_get_peeled_oid()`,
which is currently only possible when iterating over references. Other
higher-level functions like `reference_is_branch()` or similar things
can also be introduced. Last but not least, it also makes it obvious
what kind of "thing" we're working with in many cases, as a `struct
reference` will always be the fully-qualified and "raw" reference.
Hope that sheds some light on my thinking :)
Thanks!
Patrick
next prev parent reply other threads:[~2025-10-14 6:31 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 10:58 [PATCH 00/13] refs: improvements and fixes for peeling tags Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 01/13] refs: introduce wrapper struct for `each_ref_fn` Patrick Steinhardt
2025-10-07 18:05 ` Justin Tobler
2025-10-08 13:42 ` Patrick Steinhardt
2025-10-07 21:56 ` Taylor Blau
2025-10-08 15:52 ` shejialuo
2025-10-09 6:03 ` Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 02/13] refs: introduce `.ref` field for the base iterator Patrick Steinhardt
2025-10-07 14:24 ` Karthik Nayak
2025-10-08 13:44 ` Patrick Steinhardt
2025-10-08 15:03 ` Patrick Steinhardt
2025-10-07 20:19 ` Justin Tobler
2025-10-07 21:57 ` Taylor Blau
2025-10-07 10:58 ` [PATCH 03/13] refs: refactor reference status flags Patrick Steinhardt
2025-10-07 14:27 ` Karthik Nayak
2025-10-08 13:44 ` Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 04/13] refs: expose peeled object ID via the iterator Patrick Steinhardt
2025-10-07 14:52 ` Karthik Nayak
2025-10-08 13:45 ` Patrick Steinhardt
2025-10-15 8:28 ` Karthik Nayak
2025-10-07 10:58 ` [PATCH 05/13] upload-pack: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-07 16:18 ` Karthik Nayak
2025-10-08 13:45 ` Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 06/13] ref-filter: propagate peeled object ID Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 07/13] builtin/show-ref: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 08/13] refs: drop `current_ref_iter` hack Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 09/13] refs: drop infrastructure to peel via iterators Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 10/13] object: add flag to `peel_object()` to verify object type Patrick Steinhardt
2025-10-08 11:04 ` Kristoffer Haugsbakk
2025-10-07 10:58 ` [PATCH 11/13] refs: don't store peeled object IDs for invalid tags Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 12/13] ref-filter: detect broken tags when dereferencing them Patrick Steinhardt
2025-10-07 10:58 ` [PATCH 13/13] ref-filter: parse objects on demand Patrick Steinhardt
2025-10-08 11:05 ` Kristoffer Haugsbakk
2025-10-08 13:45 ` Patrick Steinhardt
2025-10-07 21:00 ` [PATCH 00/13] refs: improvements and fixes for peeling tags Junio C Hamano
2025-10-07 21:49 ` Taylor Blau
2025-10-07 23:01 ` Junio C Hamano
2025-10-08 15:50 ` [PATCH v2 00/14] " Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 01/14] refs: introduce wrapper struct for `each_ref_fn` Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 02/14] refs: introduce `.ref` field for the base iterator Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 03/14] refs: fully reset `struct ref_iterator::ref` on iteration Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 04/14] refs: refactor reference status flags Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 05/14] refs: expose peeled object ID via the iterator Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 06/14] upload-pack: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 07/14] ref-filter: propagate peeled object ID Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 08/14] builtin/show-ref: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 09/14] refs: drop `current_ref_iter` hack Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 10/14] refs: drop infrastructure to peel via iterators Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 11/14] object: add flag to `peel_object()` to verify object type Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 12/14] refs: don't store peeled object IDs for invalid tags Patrick Steinhardt
2025-10-08 16:27 ` shejialuo
2025-10-09 5:22 ` Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 13/14] ref-filter: detect broken tags when dereferencing them Patrick Steinhardt
2025-10-08 15:50 ` [PATCH v2 14/14] ref-filter: parse objects on demand Patrick Steinhardt
2025-10-09 5:38 ` [PATCH v2 00/14] refs: improvements and fixes for peeling tags Jeff King
2025-10-09 6:09 ` Patrick Steinhardt
2025-10-09 6:39 ` Jeff King
2025-10-09 7:24 ` Patrick Steinhardt
2025-10-10 5:12 ` Jeff King
2025-10-10 5:22 ` Patrick Steinhardt
2025-10-10 6:26 ` Jeff King
2025-10-10 15:29 ` Junio C Hamano
2025-10-14 6:31 ` Patrick Steinhardt [this message]
2025-10-14 16:52 ` Junio C Hamano
2025-10-09 10:11 ` Toon Claes
2025-10-09 19:37 ` Junio C Hamano
2025-10-22 6:41 ` [PATCH v3 " Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 01/14] refs: introduce wrapper struct for `each_ref_fn` Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 02/14] refs: introduce `.ref` field for the base iterator Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 03/14] refs: fully reset `struct ref_iterator::ref` on iteration Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 04/14] refs: refactor reference status flags Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 05/14] refs: expose peeled object ID via the iterator Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 06/14] upload-pack: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 07/14] ref-filter: propagate peeled object ID Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 08/14] builtin/show-ref: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 09/14] refs: drop `current_ref_iter` hack Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 10/14] refs: drop infrastructure to peel via iterators Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 11/14] object: add flag to `peel_object()` to verify object type Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 12/14] refs: don't store peeled object IDs for invalid tags Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 13/14] ref-filter: detect broken tags when dereferencing them Patrick Steinhardt
2025-10-22 6:41 ` [PATCH v3 14/14] ref-filter: parse objects on demand Patrick Steinhardt
2025-10-22 15:27 ` Junio C Hamano
2025-10-23 6:00 ` Patrick Steinhardt
2025-10-22 10:57 ` [PATCH v3 00/14] refs: improvements and fixes for peeling tags Karthik Nayak
2025-10-22 14:47 ` Junio C Hamano
2025-10-23 5:52 ` Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 " Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 01/14] refs: introduce wrapper struct for `each_ref_fn` Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 02/14] refs: introduce `.ref` field for the base iterator Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 03/14] refs: fully reset `struct ref_iterator::ref` on iteration Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 04/14] refs: refactor reference status flags Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 05/14] refs: expose peeled object ID via the iterator Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 06/14] upload-pack: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 07/14] ref-filter: propagate peeled object ID Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 08/14] builtin/show-ref: convert to use `reference_get_peeled_oid()` Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 09/14] refs: drop `current_ref_iter` hack Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 10/14] refs: drop infrastructure to peel via iterators Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 11/14] object: add flag to `peel_object()` to verify object type Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 12/14] refs: don't store peeled object IDs for invalid tags Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 13/14] ref-filter: detect broken tags when dereferencing them Patrick Steinhardt
2025-10-23 7:16 ` [PATCH v4 14/14] ref-filter: parse objects on demand Patrick Steinhardt
2025-11-04 22:07 ` Jeff King
2025-11-04 23:40 ` Junio C Hamano
2025-11-04 23:54 ` Jeff King
2025-10-23 23:06 ` [PATCH v4 00/14] refs: improvements and fixes for peeling tags Junio C Hamano
2025-10-24 5:12 ` Patrick Steinhardt
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=aO3uSz-idPWahgw7@pks.im \
--to=ps@pks$(echo .)im \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jltobler@gmail$(echo .)com \
--cc=karthik.188@gmail$(echo .)com \
--cc=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
--cc=peff@peff$(echo .)net \
/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