Han-Wen Nienhuys <hanwen@xxxxxxxxxx> 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.
