On 12/12/2023 20:24, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > >> The current code only works by chance because we only have a single >> reference backend implementation. Refactor it to instead read both refs >> via the refdb layer so that we'll also be compatible with alternate >> reference backends. > > "via the refdb" -> "via the refs API" or something here and on the > title, and possibly elsewhere in the proposed log messages and > in-code comments in patches in this series, as I've never seen a > word "refdb" used in the context of this project. > > I agree it is bad manners to be intimate with the implementation > details of the how files-backend stores HEAD and ORIG_HEAD. Hmm, I have never thought of the 'pseudo-refs' as being a part of the 'reference database' at all. ;) We seem to have pseudo-refs, special pseudo-refs and (recently) ex-pseudo-refs! This patch (well series) changes the 'status' of some, *but not all*, pseudo-refs; some graduate to full-blown refs stored as part of *a* reference database (ie reftable). As far as I recall, this has not been discussed on the ML. Why are only some chosen to become 'full' refs and others not? This is not discussed in any of the commit messages. The '.invalid' HEAD hack featured in a recent completion patch as well. [If this is because the JAVA implementation does it this way, I think it needs some thought before including it in the Git project]. Anyway, I haven't had the time to study the details here, so please ignore my uninformed ramblings! ATB, Ramsay Jones
