Re: [PATCH v7 6/6] Reftable support for git-core
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 27, 2020, 16:23 UTC
- Message-ID
- <xmqq5zfsgfti.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <CAFQ2z_PGgQ19uyjaEaJ4XMuvbkzW5fvJng3r2vYHDz4Z6pT3Aw@mail.gmail.com>
Han-Wen Nienhuys <hanwen@google.com> writes:
> So, the ref backend should manage the HEAD ref, but iteration should > not produce the HEAD ref.
Yeah, as there is a dedicated API function head_ref().
Things like ORIG_HEAD and MERGE_HEAD have always been curiosity outside the official API, but IIRC read_ref() and friends are prepared to read them [*1*], so the vocabulary may be unbounded [*2*].
These won't be listed in for_each_ref() iteration, either (think of for_each_ref() as a filtered "ls -R .git/refs/" output).
Thanks.
[Footnotes]
*1* I do not offhand know if these *_HEAD pseudo-refs are written via the refs API---it probably is the safest to arrange the ref backends in such a way that they always go to the files backend, even if HEAD and refs/* are managed by a backend different from the files one.
*2* I vaguely recall that back when ref-backend infrastructure was introduced, we had discussion on declaring that "^[A-Z_]*HEAD$" directly under $GIT_DIR/ are these special refs (and nothing else directly under $GIT_DIR/ is). I do not recall what happend to the discussion, though other folks may.