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

[Junio C Hamano <gitster@pobox.com>]

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?