Re: [PATCH v2 00/14] refs: improvements and fixes for peeling tags

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 10, 2025, 15:29 UTC
Message-ID: <xmqq8qhibwrn.fsf@gitster.g>
In-Reply-To: <aOiYFPTNLL1Fgz5V@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 6 quoted lines

> 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?