On Tue, Feb 1, 2022 at 11:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > > > We could surely add magic record types, but how would such a dance be > > performed while keeping compatibility with existing JGit clients? > > Yes. It is exactly the point of the question I asked. If it is > simple and easy to add such a new type that is ignored/skipped by > existing clients, then we can go that route. If it is simple and > easy to add a new bit per ref that existing clients would not barf, > we can use that as an alternative implementation strategy. I'm not sure that there are any JGit clients: I committed reftable support at the end of 2019. Before that time, we were running it internally at Google, but only ref storage, and without the posix part. Reflogs were never stored in refable, and I actually found a couple of bugs in Shawn's Java code. Gerrit has increasingly started using Git as a database, and the packed/loose system is just not a very good database, so that motivates the work reftable in general. But the folks who run Gerrit on a POSIX filesystem want to be sure that isn't a fringe feature, so they only want to start using it once Git itself supports it. So there is a chicken & egg problem. It's sad that we have to introduce an existence bit to make things work, but overall it is probably easier for me to do than trying to make sense of sequencer.c and how it uses refs/stash@{0}. Technically, the only obstacle I see is that we'd need to treat an existence entry especially for the purpose of compaction/gc: we can discard older entries, but we shouldn't discard the existence bit, no matter how old it is. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado