Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > On Fri, May 8, 2020 at 8:58 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Makes sense. >> >> I wonder if I should take 1-3/12 as a separate "clean-up" series and >> merge it before everything else down to 'master'? That would reduce >> the churn somewhat. > > That would be great. Do I need to send them separately, or do can you > cherry-pick the changes out of this series? For the past several days, my tree had two topics, hn/refs-cleanup (4 patches---1, 2, 3 and 11 from this series) and hn/reftable (the rest) queued separately. If everybody (including you) is happy with the former, we can just treat it as a separate "preliminary clean-up" topic and merge it down thru 'next' to 'master' and hopefully we can do so before the end of this cycle, as I do not immediately see anything controversial in them. The other topic builds on top of it, and it may have to get into a reviewable state, but at least the early "good bits" split out into a separate topic shouldn't have to wait. Then we only need to iterate on the latter part. I am wondering if we can also throw the file format documentation into the "more or less uncontroversial" pile. There may be a lot to dislike in the current "implementation" in reftable/*.c, especially when viewed in the context of this project, that makes it less appealing to review, but my understanding is that the feature as designed by Shawn and described in the format document is already in use in JGit, so even if the code may need a major update only to become viewable from some reviewers' point of view, the design it aims to implement, at least a major part of it, is more or less cast in stone. Unless we collectively decide that we will never support reftable in git-core, we need to adopt the format documentation and the way the subsystem is supposed to work as-is to be compatible, which makes it "more or less uncontroversial". It may need some copyediting, though. Also it is not clear to me if the base part (without "hash id" and incremented format version) is the only thing in such a "the other system already implements it, so compatibility concerns leave little room to change the design at this point" state, or the updated variant that allows us to support SHA-256 and other hashes is also in that state.
