Re: reftable: new ref storage format

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2017, 18:53 UTC
Message-ID: <xmqqa841poea.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAMy9T_Fuf3YoHzsLgx-fcX5OQBNXw8xOvrPEpffkYjWGBpNsMQ@mail.gmail.com>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 15 quoted lines

> On second thought, the idea of having HEAD (or maybe all pseudorefs)
> in the same system would open a few interesting possibilities that
> derive from having a global, atomic view of all references:
>
> 1. We could store backlinks from references to the symbolic references
> that refer to them. This would allow us to update the reflogs for
> symbolic refs properly. (Currently, there is special-case code to
> update the reflogs for HEAD when the reference that it points at is
> modified, but not for other symrefs.)
>
> 2. We could store "peeled" versions of symbolic refs. These would have
> to be updated whenever the pointed-at reference is updated, but that
> would have two nice advantages: HEAD would usually be resolvable based
> on the top reftable in the stack, and it would be resolvable in one
> step (without having the follow the symref explicitly).

Interesting. I think FETCH_HEAD is the only thing that would not mesh well with the "one ref records one object name, or refers to another ref" paradigm, and I think it is OK to leave it that way, even in the new pluggable ref backend world order.

It still bothers me that the way refs.c special-cases what you call pseudo refs seems somewhat inconsistent, which I found by accident the other day while running t1405 and reported in a separate thread. When we start adding a reftable backend, I suspect we'd need to dig further, but if I recall the symptom correctly, writing them out is still passed to the main (i.e. files) backend, while reading them is done directly in refs.c layer without consulting any backend, and that made it impossible to optionally tweak the filename used to store refs in the files backend.