On Thu, Feb 17 2022, Junio C Hamano wrote: > Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > >> For FETCH_HEAD, doing >> >> git fetch host refs/changes/23/123/1 && git checkout FETCH_HEAD >> >> is the standard idiom for downloading a change from Gerrit. I suspect >> there might be other similar idioms. This means we have to read them >> through the refs machinery. > > This merely means we have to read them through the object-name > machinery around get_oid(). Historically that was done by calling > repo_dwin_ref() from get_oid_basic(), which is where refs machinery > enters the picture, and because we had only files backend, it was OK > and convenient to treat .git/FETCH_HEAD and .git/refs/heads/master > in the same codepath. But there is no reason for the arrangement to > stay that way. .git/FOOBAR_HEAD files can be read as a file (we can > say we let files-backend to handle it, but we can also extract a helper > function out of it and make it clear that it truly has no dependence > on the refs machinery) while .git/refs/* can be read from the refs > machinery that may be backed by reftable backend. > >> I think the most sensible approach is to pass the read/write through >> refs_* functions, but special-case the storage, so it doesn't go >> through reftable. We already do this for FETCH_HEAD and MERGE_HEAD in >> refs_read_raw_refs. > > I think we are more or less on the same page. I do not think these > files behave like refs (they have no reflog, and they do not serve > as anchoring points for the purpose of gc/fsck) and we need a > special code path, which might be identical to the current ref-files > backend code, to handle them no matter what backend is used for true > refs. I'm not sure I get all the concerns in this thread, are we talking about having FETCH_HEAD be not-in-reftable mainly because it's multi-value? Maybe we will need these special refs on-disk forever, but it seems preferrable to pursue a plan where we use the preferred ref backend for them. That means that we can make them part of the normal ref transaction for the backend, and could eventually support a world where a repo e.g. talks to remote DB service for its refs (with shared storage for repos). For the "no reflog" is that really a critical property to maintain, or just how the file backend happens to work now? In any case weren't we talking about explicitly supporting the "explicit no reflog", "reflog only for this ref" etc. that we support in the file backend in reftable? Then we could presumably turn off the reflog for these special refs. Similarly, for "gc" etc. supporting that doesn't seem like such a big deal in that codepath, even if these end up being stored in some "real" ref store. We can just ignore them when we're checking reachability. But I may be entirely missing the point here...
