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

From: Jeff King <[email-masked]>
Date: Thu, 9 Oct 2025 02:39:56 -0400

On Thu, Oct 09, 2025 at 08:09:53AM +0200, Patrick Steinhardt wrote:

> > I do have one minor complaint, though: the name of that struct. I have a
> > feeling that the name "struct reference" may cause confusion down the
> > road because it's so generic, and because "references" and "refs" are so
> > common in the code. From the names, when would I know when to use
> > "struct reference" and when "struct ref"?
> > 
> > Could we give it a name that ties it to the iteration interface?
> > Something like iterated_ref, each_ref_data, etc?
> > 
> > I know this is minor (and will be annoying to adjust your series), but
> > I'd rather raise the point now than realize later that it's confusing
> > and try to change it then.
> 
> It is puzzling indeed. I would claim that in this case it is not `struct
> reference` that is misnamed: what it contains is as close as you get to
> a representation of a reference. It's rather `struct ref` that is
> misnamed, as it carries a lot of data that is only valid in the context
> of a remote.
> 
> Another approach could thus be to rename `struct ref` to `struct
> remote_ref`, which I would claim would be a clear win for better semantics.
> It's used in lots of places though, which is a valid counter argument.

I am not so much arguing that "struct reference" is misnamed, as that it
is sufficiently generic that people will reach for it when it is not the
appropriate tool. It is for passing the ref data to the iterator
callback, but it probably doesn't make sense in other contexts. Would we
ever expect anybody to declare their own "struct reference" in a local
function? I don't think so.

And yes, "struct ref" suffers somewhat from the same problem. It is
mostly about using refs in one specific space, but the name does not
really help clarify that. I wouldn't mind seeing that improved, but yes,
it would be a noisy patch. I don't know if remote_ref is the right name,
though (the "peer_ref" links mean we store both local and remote refs in
it, IIRC).

-Peff