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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2025, 16:52 UTC
Message-ID: <xmqqy0pdxw7a.fsf@gitster.g>
In-Reply-To: <aO3uSz-idPWahgw7@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 22 quoted lines

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

OK. The plain reference structure then would not be involved in local ref update transactions, for example. It is just "here are the refs we have", "this ref is of this type, at this path, with this value", etc. Makes sense.

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

OK.  Makes sense.  Thanks.