Patrick Steinhardt <ps@xxxxxx> writes: > ``` > if (!starts_with(iter->ref.refname, "refs/") && > !(flags & INCLUDE_ROOT_REFS || is_pseudoref(iter->ref.refname))) > continue; > ``` > > The problem I have is that it still wouldn't end up surfacing all refs > which exist in the ref backend while being computationally more > expensive. So the original usecase I had in mind when pitching this > topic isn't actually addressed. The reftable format, as a database format, may be capable of having "refs/heads/master" and "refs/heads/master/1" at the same time, but to be used as a ref backend for Git, it must refrain from surfacing both at the same time. I think it is the same deal that it should only allow "refs/*", "HEAD", and so called pseudorefs to be stored. So INCLUDE_ROOT_REFS should be sufficient as long as the "ref creation and update" side is not letting random cruft (e.g., "config") in. Isn't that sufficient? > I know that in theory, the reftable backend shouldn't contain refs other > than "refs/" or pseudo-refs anyway. But regardless of that, I think that > formulating this in the form of "root refs" is too restrictive and too > much focussed on the "files" backend. It is not "focused on". The ref namespace of Git is tree-shaped, period. The shape may have originated from its first ref backend implementation's limitation, but as we gain other backends, we are not planning to lift such limitations, are we? So we may still say "when there is a master branch, you cannot have master/1 branch (due to D/F conflict)", even if there is no notion of directory or file in a backend implementation backed by a databasy file format. "HEAD" and "CHERRY_PICK_HEAD", unlike "refs/tags/v1.0", are at the "root level", not only when they are stored in a files backend, but always when they are presented to end-users, who can tell that they are not inside "refs/".
